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 <jrottingh...@ebay.com>wrote:
> Non-binding +1
>
> Joep
> ________________________________________
> From: Eli Collins [e...@cloudera.com]
> Sent: Thursday, September 15, 2011 2:06 PM
> To: common-dev@hadoop.apache.org
> Subject: Re: [PROPOSAL] Two Jira infrastructure additions to support
> sustaining bug fixes
>
> On Thu, Sep 15, 2011 at 1:44 PM, Matt Foley <mfo...@hortonworks.com>
> wrote:
> > On Thu, Sep 15, 2011 at 1:20 PM, Eli Collins <e...@cloudera.com> 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 <mfo...@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.
> >> >
> >>
> >
>
