Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> JIRAs post-"unsplit"


Copy link to this message
-
Re: JIRAs post-"unsplit"
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB