Matt Foley
2011-09-15, 18:58
Eli Collins
2011-09-15, 20:20
Matt Foley
2011-09-15, 20:44
Eli Collins
2011-09-15, 21:06
Rottinghuis, Joep
2011-09-16, 16:21
Matt Foley
2011-09-19, 21:24
Suresh Srinivas
2011-09-15, 20:33
Kihwal Lee
2011-09-15, 20:51
Jonathan Eagles
2011-09-15, 20:53
Dhruba Borthakur
2011-09-15, 20:54
Steve Loughran
2011-09-16, 08:43
-
[PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesMatt Foley 2011-09-15, 18:58
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.
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.
+
Matt Foley 2011-09-15, 18:58
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesEli Collins 2011-09-15, 20:20
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. 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.
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, 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.
>
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. 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.
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, 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.
>
+
Eli Collins 2011-09-15, 20:20
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesMatt Foley 2011-09-15, 20:44
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.
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,
> 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
> 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.
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,
> 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
+
Matt Foley 2011-09-15, 20:44
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesEli Collins 2011-09-15, 21:06
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,
>> 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.
> 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,
>> 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.
+
Eli Collins 2011-09-15, 21:06
-
RE: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesRottinghuis, Joep 2011-09-16, 16:21
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,
>> 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
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,
>> 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
+
Rottinghuis, Joep 2011-09-16, 16:21
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesMatt Foley 2011-09-19, 21:24
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,
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,
+
Matt Foley 2011-09-19, 21:24
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesSuresh Srinivas 2011-09-15, 20:33
Matt,
+1 for Target Version field. +1 for naming convention for the jira patch
attachments.
Regards,
Suresh
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, 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.
>
+1 for Target Version field. +1 for naming convention for the jira patch
attachments.
Regards,
Suresh
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, 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.
>
+
Suresh Srinivas 2011-09-15, 20:33
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesKihwal Lee 2011-09-15, 20:51
+1 for this combination.
Kihwal
On 9/15/11 3:33 PM, "Suresh Srinivas" <[EMAIL PROTECTED]> wrote:
Matt,
+1 for Target Version field. +1 for naming convention for the jira patch
attachments.
Regards,
Suresh
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, 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.
>
Kihwal
On 9/15/11 3:33 PM, "Suresh Srinivas" <[EMAIL PROTECTED]> wrote:
Matt,
+1 for Target Version field. +1 for naming convention for the jira patch
attachments.
Regards,
Suresh
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, 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.
>
+
Kihwal Lee 2011-09-15, 20:51
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesJonathan Eagles 2011-09-15, 20:53
+1 great suggestions to dev process
On Thu, Sep 15, 2011 at 1:58 PM, 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, 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.
>
On Thu, Sep 15, 2011 at 1:58 PM, 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, 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.
>
+
Jonathan Eagles 2011-09-15, 20:53
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesDhruba Borthakur 2011-09-15, 20:54
+1. I faced the same problems while doing the 0.20-append branch.
thanks
dhruba
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, 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.
>
--
Connect to me at http://www.facebook.com/dhruba
thanks
dhruba
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, 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.
>
--
Connect to me at http://www.facebook.com/dhruba
+
Dhruba Borthakur 2011-09-15, 20:54
-
Re: [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixesSteve Loughran 2011-09-16, 08:43
On 15/09/2011 19:58, Matt Foley 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.
seen this.
Another way to do it could be to create sub-issues, one for each branch,
so you have a super-issue for all branches, and a sub-issue for the
individual branches. Then we'd need a tag for "test-branch" which could
be used by jenkins to know which branch to patch-test against. ]]
The advantage of this approach is that the sub-task mechanism is built
into JIRA, lets you see at a glance from the super-task which branches
are still open, and lets you have a sub-lifecycle (progress, wontfix,
logged hours) for each branch, and you could easily separate the jenkins
outputs.
The risk is that discussions would take place in the sub-tasks, not the
supertask, but that is a team process issue
> 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.
seen this.
Another way to do it could be to create sub-issues, one for each branch,
so you have a super-issue for all branches, and a sub-issue for the
individual branches. Then we'd need a tag for "test-branch" which could
be used by jenkins to know which branch to patch-test against. ]]
The advantage of this approach is that the sub-task mechanism is built
into JIRA, lets you see at a glance from the super-task which branches
are still open, and lets you have a sub-lifecycle (progress, wontfix,
logged hours) for each branch, and you could easily separate the jenkins
outputs.
The risk is that discussions would take place in the sub-tasks, not the
supertask, but that is a team process issue
+
Steve Loughran 2011-09-16, 08:43
