On Thu, Sep 15, 2011 at 1:44 PM, Matt Foley <mfo...@hortonworks.com> wrote: > 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. >
Awesome. +1 > 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. >> > >> >
