+1. I faced the same problems while doing the 0.20-append branch. thanks dhruba
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. > -- Connect to me at http://www.facebook.com/dhruba
