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