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

Reply via email to