Matt Foley 2011-09-15, 18:58
Eli Collins 2011-09-15, 20:20
Matt Foley 2011-09-15, 20:44
Eli Collins 2011-09-15, 21:06
Rottinghuis, Joep 2011-09-16, 16:21
Matt Foley 2011-09-19, 21:24
Suresh Srinivas 2011-09-15, 20:33
-Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixes
+1 for this combination.
On 9/15/11 3:33 PM, "Suresh Srinivas" <[EMAIL PROTECTED]> wrote:
+1 for Target Version field. +1 for naming convention for the jira patch
On Thu, Sep 15, 2011 at 11:58 AM, Matt Foley <[EMAIL PROTECTED]> 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
> 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
> 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
> 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
> 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
> 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.
Jonathan Eagles 2011-09-15, 20:53
Dhruba Borthakur 2011-09-15, 20:54
Steve Loughran 2011-09-16, 08:43