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?
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 [[email protected]] Sent: Monday, June 13, 2011 1:37 PM To: [email protected] Subject: Re: JIRAs post-"unsplit" On Mon, Jun 13, 2011 at 11:51 AM, Konstantin Boudnik <[email protected]> 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
