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.
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? Cos 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
