Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixes


Copy link to this message
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixes
Thanks for your support.  I've opened
    INFRA-3937 Request for Hadoop Jiras: add custom field "Target Version/s"
[field type Version Picker]
if anyone wishes to follow the issue.
--Matt
On Fri, Sep 16, 2011 at 9:21 AM, Rottinghuis, Joep <[EMAIL PROTECTED]>wrote:

> Non-binding +1
>
> Joep
> ________________________________________
> From: Eli Collins [[EMAIL PROTECTED]]
> Sent: Thursday, September 15, 2011 2:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Two Jira infrastructure additions to support
> sustaining bug fixes
>
> On Thu, Sep 15, 2011 at 1:44 PM, Matt Foley <[EMAIL PROTECTED]>
> wrote:
> > On Thu, Sep 15, 2011 at 1:20 PM, Eli Collins <[EMAIL PROTECTED]> 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 <[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
> >> 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,