On Tue, Jun 14, 2011 at 9:35 AM, Rottinghuis, Joep <jrottingh...@ebay.com>wrote:
> Project un-split definitely simplifies things. > > Todd, if people add a watch based on patches, would they not miss > notifictions for those entries in an earlier phase of their lifecycle? > For example when issues are just reported, discussed and assigned, but no > patch has been attached yet? > > Another thought that Alejandro just suggested offline is to use JIRA components rather than just the file paths. So, assuming there is a bot that watches the JIRA, it would be easy enough to allow you to permawatch a component (JIRA itself doesn't give this option). Then, assuming the patch is assigned the right components, it will be seen by people who care early on. If it's not given the right components, then it will be seen once you upload a patch. > A separate HADOOPX Jira project would eliminate such issues. > > It does raise another question though: What happens if an issue starts out > in one area, and then turns out to require changes in other areas? > Would one then first create a HADOOP-x, a HDFS-y, or MAPREDUCE-z and then > when it turns out other components are involved a new HADOOPX- referring to > such earlier Jira? > > Cheers, > > Joep > > ________________________________________ > From: Todd Lipcon [t...@cloudera.com] > Sent: Monday, June 13, 2011 1:37 PM > To: general@hadoop.apache.org > Subject: Re: JIRAs post-"unsplit" > > On Mon, Jun 13, 2011 at 11:51 AM, Konstantin Boudnik <c...@apache.org> > wrote: > > > 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. > > > > Yea, perhaps we just need the QA bot to be smart enough that it could > handle > a cross-project patch attached to HADOOP? Maybe we do something crazy and > make a new HADOOPCROSS jira for patches that affect multiple projects? > (just > brainstorming here...) > > > > 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? > > > > Right, that's the idea. You'd be added as a watcher (and get notified) for > any patch that touches the area you care about, regardless of whether it > also touches some other areas. > > -Todd > -- Todd Lipcon Software Engineer, Cloudera
