You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by si...@insession.com on 2005/07/20 02:01:27 UTC
Proper use of Jira for defects that occur in multiple branches/releases (was
Re: Outstanding tasks for M4)
David Jencks <dj...@gluecode.com> wrote on 20/07/2005 03:24:46 AM:
> what is the proper use of Jira for defects that occur in multiple
> branches/releases? There are at least 2 issues fixed in head that need
> to be backported
I found an answer at
http://jira.atlassian.com/browse/JRA-7186?decorator=printable
A user asked the question "We are now considering adding version
management to a project. A user has this question: What if a fix has been
slated for multiple versions, but the developer has only fixed it in one
version so far? There is no way to mark the issue as resolved for one
version but not the other. Maybe you can help explain how this workflow
would be handled within JIRA."
The answer was "The best way to deal with this situation would be to
create a new issue for each version and link these issues if necessary.
This way you will have one issue representing each piece of work that
needs to be done and the progress on each version can be tracked
separately. Clone issue functionality can ve handy here."
Although the recommendation involves creating more issues (the clone issue
function should make it easy), I think it is the safest way to manage
changes to multiple versions. For example, someone may not have the time
to merge a fix into all branches immediately, this method allows them to
track the work outstanding on each branch.
It also would remove confusion in a scenario where someone fixes HEAD and
then merges the fix into a branch, but makes a mistake in the merging in
the branch. The issue for HEAD can remain closed and the issue for the
branch can be reopened/kept open.
Comments as to whether this is the way we want to go moving forward?
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Re: Proper use of Jira for defects that occur in multiple branches/releases
(was Re: Outstanding tasks for M4)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Erin Mulder wrote, On 7/21/2005 4:17 AM:
>Dain Sundstrom wrote:
>
>
>>On Jul 20, 2005, at 12:01 PM, David Jencks wrote:
>>
>>
>>
>>>well,
>>>-1000
>>>
>>>I feel pretty strongly about this too. Obviously its better to fix
>>>stuff in all branches at once, but it won't always be possible,
>>>especially after 1.3 diverges from 1.0, 2.4 vs 1.1, 5.6 vs 2.1 etc.
>>>At some point you have to say that there are different issues in
>>>different branches, even though the symptom is the same. I think the
>>>jira guys know of what they speak when the recommend using multiple
>>>entries.
>>>
>>>
>>Good point. How about we only split an issue when we fix it in one
>>branch and not the others? I would suspect that this will be a rare
>>event... at lest for a the next few years :)
>>
>>
>
>You could also use sub-tasks in JIRA if those are enabled. That lets
>you keep it as a single issue, but break it out into a couple of pieces
>and track their progress individually. The whole issue remains open
>until they're all closed. Meanwhile, it shows a little graphic of how
>many subtasks are complete.
>
>(The JIRA interface for this is pretty nice. There are a couple of
>steps for adding the first subtask, but after that, the main issue
>screen shows a little table of subtasks and lets you add a new one by
>typing a title in the last row and clicking "Add".)
>
>Just a thought. :)
>
>
Yeah, I like sub-tasks. I wish they were turned on.
Regards,
Alan
Re: Proper use of Jira for defects that occur in multiple branches/releases
(was Re: Outstanding tasks for M4)
Posted by Erin Mulder <me...@alumni.princeton.edu>.
Dain Sundstrom wrote:
> On Jul 20, 2005, at 12:01 PM, David Jencks wrote:
>
>> well,
>> -1000
>>
>> I feel pretty strongly about this too. Obviously its better to fix
>> stuff in all branches at once, but it won't always be possible,
>> especially after 1.3 diverges from 1.0, 2.4 vs 1.1, 5.6 vs 2.1 etc.
>> At some point you have to say that there are different issues in
>> different branches, even though the symptom is the same. I think the
>> jira guys know of what they speak when the recommend using multiple
>> entries.
>
> Good point. How about we only split an issue when we fix it in one
> branch and not the others? I would suspect that this will be a rare
> event... at lest for a the next few years :)
You could also use sub-tasks in JIRA if those are enabled. That lets
you keep it as a single issue, but break it out into a couple of pieces
and track their progress individually. The whole issue remains open
until they're all closed. Meanwhile, it shows a little graphic of how
many subtasks are complete.
(The JIRA interface for this is pretty nice. There are a couple of
steps for adding the first subtask, but after that, the main issue
screen shows a little table of subtasks and lets you add a new one by
typing a title in the last row and clicking "Add".)
Just a thought. :)
Cheers,
Erin
Re: Proper use of Jira for defects that occur in multiple branches/releases (was Re: Outstanding tasks for M4)
Posted by David Jencks <dj...@gluecode.com>.
On Jul 20, 2005, at 1:04 PM, Dain Sundstrom wrote:
> On Jul 20, 2005, at 12:01 PM, David Jencks wrote:
>
>> well,
>> -1000
>>
>> I feel pretty strongly about this too. Obviously its better to fix
>> stuff in all branches at once, but it won't always be possible,
>> especially after 1.3 diverges from 1.0, 2.4 vs 1.1, 5.6 vs 2.1 etc.
>> At some point you have to say that there are different issues in
>> different branches, even though the symptom is the same. I think the
>> jira guys know of what they speak when the recommend using multiple
>> entries.
>
> Good point. How about we only split an issue when we fix it in one
> branch and not the others? I would suspect that this will be a rare
> event... at lest for a the next few years :)
+10 (moderating my overenthusiasm :-)
I'm even willing to publicly support giving people a couple days
latitude between branch fixes before thinking another linked issue is
essential.
david jencks
>
> -dain
>
Re: Proper use of Jira for defects that occur in multiple branches/releases (was Re: Outstanding tasks for M4)
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 20, 2005, at 12:01 PM, David Jencks wrote:
> well,
> -1000
>
> I feel pretty strongly about this too. Obviously its better to fix
> stuff in all branches at once, but it won't always be possible,
> especially after 1.3 diverges from 1.0, 2.4 vs 1.1, 5.6 vs 2.1
> etc. At some point you have to say that there are different issues
> in different branches, even though the symptom is the same. I
> think the jira guys know of what they speak when the recommend
> using multiple entries.
Good point. How about we only split an issue when we fix it in one
branch and not the others? I would suspect that this will be a rare
event... at lest for a the next few years :)
-dain
Re: Proper use of Jira for defects that occur in multiple
branches/releases (was Re: Outstanding tasks for M4)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Talk about battle of the exaggerations! :)
Generally speaking, I prefer not to have multiple issues: if you
put attachments and comments and stuff on one, or even edit it to change
the description entirely, any "matching" issues are unafected. The "link"
is pretty minor in the UI. This could result in two issues that are
supposed to be the same inadvertently leading to totally different changes
in two branches or whatever.
That said, if branches are divergent enough that the same solution
does not work even if the problem is the same, I suppose I would be in
favor of separate issues. I suspect this would be true of 1.3 vs 5.6.
Aaron
On Wed, 20 Jul 2005, David Jencks wrote:
> > +1000
> >
> > I feel pretty strongly about this. Is there some big problem that
> > would cause us to split an issue across several Jira entries?
> well,
> -1000
>
> I feel pretty strongly about this too. Obviously its better to fix
> stuff in all branches at once, but it won't always be possible,
> especially after 1.3 diverges from 1.0, 2.4 vs 1.1, 5.6 vs 2.1 etc. At
> some point you have to say that there are different issues in different
> branches, even though the symptom is the same. I think the jira guys
> know of what they speak when the recommend using multiple entries.
>
> david jencks
>
>
Re: Proper use of Jira for defects that occur in multiple branches/releases (was Re: Outstanding tasks for M4)
Posted by David Jencks <dj...@gluecode.com>.
On Jul 20, 2005, at 11:55 AM, Dain Sundstrom wrote:
> On Jul 20, 2005, at 3:07 AM, Alan D. Cabrera wrote:
>
>> I feel that this should be represented by a single Jira issue. Jira
>> allows one to select multiple versions in its "fixed" field. Also,
>> when the issue gets fixed, the fix should be applied to *all*
>> relevant versions immediately. Waiting only increases the chance
>> that changes won't be propagated across all versions. Having
>> multiple people perform the same fixed in different branches sounds
>> like trouble waiting to happen.
>
> +1000
>
> I feel pretty strongly about this. Is there some big problem that
> would cause us to split an issue across several Jira entries?
well,
-1000
I feel pretty strongly about this too. Obviously its better to fix
stuff in all branches at once, but it won't always be possible,
especially after 1.3 diverges from 1.0, 2.4 vs 1.1, 5.6 vs 2.1 etc. At
some point you have to say that there are different issues in different
branches, even though the symptom is the same. I think the jira guys
know of what they speak when the recommend using multiple entries.
david jencks
Re: Proper use of Jira for defects that occur in multiple branches/releases (was Re: Outstanding tasks for M4)
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 20, 2005, at 3:07 AM, Alan D. Cabrera wrote:
> I feel that this should be represented by a single Jira issue.
> Jira allows one to select multiple versions in its "fixed" field.
> Also, when the issue gets fixed, the fix should be applied to *all*
> relevant versions immediately. Waiting only increases the chance
> that changes won't be propagated across all versions. Having
> multiple people perform the same fixed in different branches sounds
> like trouble waiting to happen.
+1000
I feel pretty strongly about this. Is there some big problem that
would cause us to split an issue across several Jira entries?
-dain
Re: Proper use of Jira for defects that occur in multiple branches/releases
(was Re: Outstanding tasks for M4)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Geir Magnusson Jr. wrote, On 7/20/2005 4:46 PM:
>
> On Jul 19, 2005, at 8:01 PM, sissonj@insession.com wrote:
>
>> David Jencks <dj...@gluecode.com> wrote on 20/07/2005 03:24:46 AM:
>>
>>
>>> what is the proper use of Jira for defects that occur in multiple
>>> branches/releases? There are at least 2 issues fixed in head that
>>> need
>>> to be backported
>>>
>>
>>
>>
>> The answer was "The best way to deal with this situation would be to
>> create a new issue for each version and link these issues if necessary.
>> This way you will have one issue representing each piece of work that
>> needs to be done and the progress on each version can be tracked
>> separately. Clone issue functionality can ve handy here."
>>
>> Although the recommendation involves creating more issues (the clone
>> issue
>> function should make it easy), I think it is the safest way to manage
>> changes to multiple versions. For example, someone may not have the
>> time
>> to merge a fix into all branches immediately, this method allows
>> them to
>> track the work outstanding on each branch.
>>
>> It also would remove confusion in a scenario where someone fixes
>> HEAD and
>> then merges the fix into a branch, but makes a mistake in the
>> merging in
>> the branch. The issue for HEAD can remain closed and the issue for the
>> branch can be reopened/kept open.
>>
>> Comments as to whether this is the way we want to go moving forward?
>
This email slipped by me and so I'll have to usurp Geir's email.
I feel that this should be represented by a single Jira issue. Jira
allows one to select multiple versions in its "fixed" field. Also, when
the issue gets fixed, the fix should be applied to *all* relevant
versions immediately. Waiting only increases the chance that changes
won't be propagated across all versions. Having multiple people perform
the same fixed in different branches sounds like trouble waiting to happen.
Regards,
Alan
Re: Proper use of Jira for defects that occur in multiple branches/releases (was Re: Outstanding tasks for M4)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 19, 2005, at 8:01 PM, sissonj@insession.com wrote:
> David Jencks <dj...@gluecode.com> wrote on 20/07/2005 03:24:46 AM:
>
>
>> what is the proper use of Jira for defects that occur in multiple
>> branches/releases? There are at least 2 issues fixed in head that
>> need
>> to be backported
>>
>
>
>
> The answer was "The best way to deal with this situation would be to
> create a new issue for each version and link these issues if
> necessary.
> This way you will have one issue representing each piece of work that
> needs to be done and the progress on each version can be tracked
> separately. Clone issue functionality can ve handy here."
>
> Although the recommendation involves creating more issues (the
> clone issue
> function should make it easy), I think it is the safest way to manage
> changes to multiple versions. For example, someone may not have
> the time
> to merge a fix into all branches immediately, this method allows
> them to
> track the work outstanding on each branch.
>
> It also would remove confusion in a scenario where someone fixes
> HEAD and
> then merges the fix into a branch, but makes a mistake in the
> merging in
> the branch. The issue for HEAD can remain closed and the issue for
> the
> branch can be reopened/kept open.
>
> Comments as to whether this is the way we want to go moving forward?
+1
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org