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