hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: JIRAs post-"unsplit"
Date Mon, 13 Jun 2011 20:37:08 GMT
On Mon, Jun 13, 2011 at 11:51 AM, Konstantin Boudnik <cos@apache.org> wrote:

> I tend to agree: JIRA separation was the benefit of the split.
>
> I'd rather keep the current JIRA split in effect (e.g. separate JIRA
> projects
> for separate Hadoop components; don't recombine them) and file patches in
> the
> same way (for common, hdfs, mapreduce). If a cross component patch is
> needed
> then HADOOP project JIRA can be used for tracking, patches, etc.
>

Yea, perhaps we just need the QA bot to be smart enough that it could handle
a cross-project patch attached to HADOOP? Maybe we do something crazy and
make a new HADOOPCROSS jira for patches that affect multiple projects? (just
brainstorming here...)


> Tree-based watch-list seems like a great idea, but won't it narrow the
> scope
> somehow? Are you saying that if I am interested in say
> hdfs/src/c++/libhdfs,
> but a JIRA is open which affects libhdfs and something else (e.g. NameNode)
> I
> will still get the notification?
>

Right, that's the idea. You'd be added as a watcher (and get notified) for
any patch that touches the area you care about, regardless of whether it
also touches some other areas.

-Todd

On Mon, Jun 13, 2011 at 11:28AM, Todd Lipcon wrote:
> > After the "project unsplit" this weekend, we're now back to a place where
> we
> > have a single SVN/git tree that encompasses all of the subprojects. This
> > opens up the next question: should we merge the JIRAs and allow a single
> > issue to have a patch which spans projects?
> >
> > My thoughts are:
> > - the biggest pain point with the project split is dealing with
> > cross-project patches
> > - one of the biggest reasons we did the project split was that the
> combined
> > traffic from the HADOOP JIRA was hard to follow for people who really
> care
> > about certain subprojects.
> > - the jira split is a coarse-grained way of allowing people to watch just
> > the sub-areas they care about.
> >
> > So, I was thinking the following... what if there were a way to watch
> JIRAs
> > based on subtrees? I'm imagining a web page where any community user
> could
> > have an account and manage a "watch list" of subtrees. If you want to
> watch
> > all MR jiras, you could simply watch mapreduce/*. If you care only about
> > libhdfs, you could watch hdfs/src/c++/libhdfs, etc. Then a bot would
> watch
> > all patches attached to JIRA, and any time a patch is uploaded that
> touches
> > something on your watch list, it automatically adds you as a watcher on
> the
> > ticket and sends you a notification via email. It would also be easy to
> set
> > up a watch based on patch size, for example.
> >
> > I think even if we don't recombine the JIRAs, this might be a handy way
> to
> > cut down on mailing list traffic for contributors who have a more narrow
> > focus on certain areas of the code.
> >
> > Does this sound useful? I don't know if/when I'd have time to build such
> a
> > thing, but if the community thinks it would be really helpful, I might
> > become inspired.
> >
> > -Todd
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message