On Thu, Sep 15, 2011 at 1:20 PM, Eli Collins <e...@cloudera.com> wrote:
> Hey Matt, > > Thanks for the proposal, agree we should sort these out. > > Wrt #1 IIUC the new workflow would be to use Target Version like we > use Fix Version today, but only set the Fix Version when we actually > commit to the given branch for the release. Exactly. > Seems reasonable. > Definitely better than creating a separate jira per branch. > > Wrt #2 I think we can handle this by people following the patch naming > guidelines (in http://wiki.apache.org/hadoop/HowToContribute) and > closing out HADOOP-7435. > I'm okay with that. And that change to Jira would probably be hard to get accepted by Infra anyway. I've transcribed the patch naming convention into HADOOP-7435, and assigned it to myself. Thanks, --Matt Thanks, > Eli > > On Thu, Sep 15, 2011 at 11:58 AM, Matt Foley <mfo...@hortonworks.com> > wrote: > > Hi all, > > for better or worse, the Hadoop community works in multiple branches. We > > have to do sustaining work on 0.20, even while we hope that 0.23 will > > finally replace it. Even after that happens, we will then need to do > > sustaining releases on 0.23 while future development goes into 0.24 or > 0.25, > > and so on. > > > > This is the price we pay for having this stuff actually in use in > > production. That's a good thing! > > And it's been that way in every software company I've worked in. > > > > My current efforts as release manager for 0.20.205 have made a couple > > deficiencies in our Jira infrastructure painfully obvious. So I would > like > > to propose two changes that will make it way easier and more reliable to > > handle patches for sustaining bug fixes. But I wanted to bounce them off > > you and make sure they have community support before asking the > > Infrastructure team to look at them. > > > > > > 1. Add a custom field "Target Version/s" [list]. > > > > Motivation: When making a release, one wants to query all Jiras marked > fixed > > in this release. This can't be done reliably with current usage. > > Also, one wants to be able to query all open issues targeted for a given > > branch. This can't be done reliably either. > > > > Why current usage is deficient: Currently we have "Affects Version/s" > and > > "Fix Version/s". But the Fix Versions is being overloaded. It is used > to > > mean "should be fixed in" (target versions) while the bug is open, and > "is > > fixed in" (fix versions) after the bug is resolved. That's fine if > there's > > only one branch in use. But if a fix is targeted for both A and B, and > it's > > actually committed to A but not yet to B, there's no way to query the > state > > of the fix. The bug appears open for both (or sometimes it's incorrectly > > closed for both!). You have to manually visit the individual bug report > and > > review the SubversionCommits. This might be automatable, but it sure > isn't > > easily expressed. > > > > If we add a Target Versions field, then intent and completion can be > > separately marked (in the Target Versions and Fix Versions, > respectively), > > and simple queries can clearly differentiate the cases. > > > > > > 2. Add "target branch/s" field to Attachments metadata (or if that's not > > feasible, establish naming convention for Attachments to include this > info) > > > > Motivation: Enable CI test-patch on patches targeted for non-trunk, as > well > > as make the target clear to human viewers. > > > > If this field can be added (I'm not sure Jira supports it), I suggest > adding > > it to the "Attach Files" dialogue box, and displaying it in the > Attachments > > and Manage Attachments views. If the Infra team says Jira can't support > it, > > then we (Hadoop dev) should talk about an unambiguous naming convention. > > > > If this meta-datum were available, it should be fairly easy to modify the > > automated test-patch process to test each patch against its intended > target > > branch. (This process is managed internally by members of the Hadoop dev > > team, and I can help with it.) This would give the usual benefits of CI > to > > our sustaining processes as well as mainstream development. > > > > > > If you like either or both of these ideas, kindly +1 them. If it's a bad > > idea, by all means say why. > > Absent negative feedback, I'm planning to open Infrastructure requests in > a > > few days. > > >
