Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CA+z3+9E=aPm7bV-wSu0JzesMcZaJaFDneMmchyCjY6z5nRC+SQ@mail.gmail.com>
References: 
 <CA+z3+9E=aPm7bV-wSu0JzesMcZaJaFDneMmchyCjY6z5nRC+SQ@mail.gmail.com>
Date: Thu, 15 Sep 2011 13:33:50 -0700
Message-ID: 
 <CADdVdVHJHfTUaSyTco1NVX6gAacznDmco2pv=j8wECRdSa4R4w@mail.gmail.com>
Subject: Re: [PROPOSAL] Two Jira infrastructure additions to support
 sustaining bug fixes
From: Suresh Srinivas <suresh@hortonworks.com>
To: common-dev@hadoop.apache.org
Content-Type: multipart/alternative; boundary=001636ef09005b5c2504ad00cb9a

--001636ef09005b5c2504ad00cb9a
Content-Type: text/plain; charset=ISO-8859-1

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.
>

--001636ef09005b5c2504ad00cb9a--