Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of eli@cloudera.com designates
 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+z3+9Gd1VvkcV=VX_RS0crJy5UDw48J5RuZyCQ3n=-Ez+SkxQ@mail.gmail.com>
References: 
 <CA+z3+9E=aPm7bV-wSu0JzesMcZaJaFDneMmchyCjY6z5nRC+SQ@mail.gmail.com>
	<CAPn_vTsUHgMgEJ8_G+7cYdsAvHUfr2gffTrvyY68Qdafpr6T1A@mail.gmail.com>
	<CA+z3+9Gd1VvkcV=VX_RS0crJy5UDw48J5RuZyCQ3n=-Ez+SkxQ@mail.gmail.com>
Date: Thu, 15 Sep 2011 14:06:04 -0700
Message-ID: 
 <CAPn_vTuwDhdFEAS=qAdBBvN-7pgmoQ-qSu6MFqw2MW_GM+7Eyw@mail.gmail.com>
Subject: Re: [PROPOSAL] Two Jira infrastructure additions to support
 sustaining bug fixes
From: Eli Collins <eli@cloudera.com>
To: common-dev@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 15, 2011 at 1:44 PM, Matt Foley <mfoley@hortonworks.com> wrote:
> On Thu, Sep 15, 2011 at 1:20 PM, Eli Collins <eli@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. =A0And 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 assign=
ed
> it to myself.
>


Awesome.  +1


> Thanks,
> --Matt
>
> Thanks,
>> Eli
>>
>> 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. =
=A0We
>> > have to do sustaining work on 0.20, even while we hope that 0.23 will
>> > finally replace it. =A0Even after that happens, we will then need to d=
o
>> > 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. =A0That'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. =A0So I wou=
ld
>> like
>> > to propose two changes that will make it way easier and more reliable =
to
>> > handle patches for sustaining bug fixes. =A0But I wanted to bounce the=
m 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. =A0This can't be done reliably with current usage.
>> > Also, one wants to be able to query all open issues targeted for a giv=
en
>> > branch. =A0This can't be done reliably either.
>> >
>> > Why current usage is deficient: =A0Currently we have "Affects Version/=
s"
>> and
>> > "Fix Version/s". =A0But the Fix Versions is being overloaded. =A0It 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. =A0That's fine if
>> there's
>> > only one branch in use. =A0But 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. =A0The bug appears open for both (or sometimes it's incorr=
ectly
>> > closed for both!). =A0You have to manually visit the individual bug re=
port
>> and
>> > review the SubversionCommits. =A0This might be automatable, but it sur=
e
>> 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 n=
ot
>> > 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 suppor=
t
>> it,
>> > then we (Hadoop dev) should talk about an unambiguous naming conventio=
n.
>> >
>> > 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 d=
ev
>> > team, and I can help with it.) =A0This would give the usual benefits o=
f CI
>> to
>> > our sustaining processes as well as mainstream development.
>> >
>> >
>> > If you like either or both of these ideas, kindly +1 them. =A0If it's =
a bad
>> > idea, by all means say why.
>> > Absent negative feedback, I'm planning to open Infrastructure requests=
 in
>> a
>> > few days.
>> >
>>
>