-Re: JIRAs post-"unsplit"
Konstantin Boudnik 2011-06-13, 18:51
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?
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 Lipcon
> Software Engineer, Cloudera