On Mon, Jun 13, 2011 at 11:51 AM, Konstantin Boudnik <c...@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
