hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Srinivas <sur...@hortonworks.com>
Subject Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixes
Date Thu, 15 Sep 2011 20:33:50 GMT
Matt,

+1 for Target Version field. +1 for naming convention for the jira patch
attachments.

Regards,
Suresh

On Thu, Sep 15, 2011 at 11:58 AM, Matt Foley <mfoley@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message