Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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,
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB