On Mon, Jun 13, 2011 at 01:37PM, Todd Lipcon wrote: > 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...)
Correct me if I'm wrong but in the new structure cross-component patch differs from a component one by a patch level (i.e. p0 vs p1 if looked from common/trunk), right? I guess the bot can be hacked to use this distinction thus saving us an extra JIRA project which will merely serve the purpose of meta-project. cos > > 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
