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

Reply via email to