[cle-release-team] JIRA Version Maintenance
Steve Swinsburg
steve.swinsburg at gmail.com
Wed Dec 5 14:33:47 PST 2012
Even if a fix version is sitting there since 2.3, it shouldn't cause a problem since the issue is unresolved. When the issue actually gets fixed then whoever does it should make sure the values are correct. Likewise for merge fields.
Cheers,
S
Sent from my iPad
On 04/12/2012, at 19:58, Jean-Francois Leveque <jean-francois.leveque at upmc.fr> wrote:
> The issue that remains is when whenever user-requeted or developer-intended version fix stays and the issue is fixed in a later release.
>
> We have Fixed/Closed issues with 2 different Fix Versions and one of the two is not true. Sometimes there's a merge request for the maintenance branch of the unfixed version in Fix Version. :(
>
> J-F
>
> On 03/12/2012 22:52, Steve Swinsburg wrote:
>> The use of that field as I describe is in the Sakai Jira Guidelines:
>>
>> https://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines
>>
>> * The *Fix Version* should be left set to the default of Unknown.
>> The project teams will set the Fix Version once they have had time
>> to review the issue and estimate when they believe they will be
>> able to address it.
>>
>>
>> and
>>
>> * *Fix Version* - Version(s) for which an issue is *anticipated to
>> be fixed* (for Unresolved issues) or in which it is *actually
>> fixed* (for Resolved/Closed and Fixed issues).
>>
>>> I think the issue is that even though a ticket is "Resolved->Fixed" it
>>> doesn't mean it's going to actually be in the release until it's
>>> "Verified->Fixed" or "Closed->Fixed". (Meaning it passed QA and it was
>>> merged into the appropriate branches)
>>
>> That is not how the workflow resolution goes though. Once an issue is
>> resolved, it is tested, then merged, then closed. Closed means no other
>> activity. Once a merge goes to the branch, unless you back it out, it
>> will be in the release.
>>
>> Also in the Sakai Jira Guidelines:
>>
>> Release Manager merges the issue (if it is a bug) to previous supported
>> and affected releases
>>
>> * The associated version merge status is set to *Resolved (*see**
>> #MergeStatus
>> <https://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines#SakaiJiraGuidelines-MergeStatus>
>> )
>> * The issue is *Closed* by the Release Manager when the last merge
>> has been completed
>>
>>
>>
>> cheers,
>> S
>>
>>
>> On 04/12/2012, at 7:11 AM, Matthew Jones <matthew at longsight.com
>> <mailto:matthew at longsight.com>> wrote:
>>
>>> I posted this to the meeting for the release call next week. I don't
>>> remember discussing this and only 1-2 people actually use it like
>>> this. In general the only people who set the fix version are the
>>> people on the release team setting the actual fix version. The one or
>>> two people who were previously using it as a targeted fix version
>>> aren't doing it any longer. We used the tag of 291triage for items
>>> targeted for the 2.9.1 release. I think the issue is that even though
>>> a ticket is "Resolved->Fixed" it doesn't mean it's going to actually
>>> be in the release until it's "Verified->Fixed" or "Closed->Fixed".
>>> (Meaning it passed QA and it was merged into the appropriate branches)
>>>
>>> So what this means is that the only fixes really in a release are the
>>> ones that pass the filter "Fix Version=<Specific Version> AND (Status
>>> = Verified or Status = Closed) and Resolution = Fixed". Everything in
>>> a past release that matches the version but not the other criteria was
>>> just a targeted fix version that needs to be cleaned up (or changed to
>>> another future version?)
>>>
>>>
>>> On Sun, Dec 2, 2012 at 6:41 PM, Steve Swinsburg
>>> <steve.swinsburg at gmail.com <mailto:steve.swinsburg at gmail.com>> wrote:
>>>
>>> Seems that the first comment on the Atlassian Jira issue is likely
>>> why it was closed as won't fix. The field can be used in various
>>> ways and depending on its state (which is either fixed or not
>>> fixed), the meaning becomes clear:
>>>
>>> https://jira.atlassian.com/browse/JRA-22225?focusedCommentId=208932&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208932
>>> <https://jira.atlassian.com/browse/JRA-22225?focusedCommentId=208932&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208932>
>>>
>>> When I send an issue to development, I set the fix-for version as
>>> the target ("I would like it to be fixed in this version"). While
>>> an issue is unresolved (i.e. "Open"), the field can simply always
>>> be interpreted as a future/target fix-for version.
>>>
>>> However, once a developer fixes an issue, only he/she knows
>>> exactly which branch or code base the fix is actually being
>>> committed to. So, as soon as the issue's resolution is set (i.e.
>>> "Fixed"), the meaning of the field changes to a past/fixed in version.
>>>
>>> It's really quite simple. Unresolved issues show the fix-for
>>> version as meaning targeted to be fixed in that version, and
>>> resolved issues show the fix-for version as meaning fixed in that
>>> version. Since an issue can only be resolved or unresolve, but not
>>> both, the duality of the meaning of that field is not confusing at
>>> all and makes maintenance of issues so much simpler.
>>>
>>>
>>>
>>> I thought we discussed this issue a while back and it was fine to
>>> use the fields in this way.
>>>
>>> cheers,
>>> Steve
>>>
>>> On 03/12/2012, at 10:37 AM, Steve Swinsburg
>>> <steve.swinsburg at gmail.com <mailto:steve.swinsburg at gmail.com>> wrote:
>>>
>>>> Well I always use the Fix Version as both an intended fix version
>>>> and actual fix version. I dont find it confusing at all. There is
>>>> a separate field called 'Resolution' so if you use them in
>>>> conjunction there is no issue.
>>>>
>>>> Fix Version: 2.9.1, Resolution: Unresolved - we want to fix it in
>>>> 2.9.1 but its not done yet. Fee free to fix it.
>>>> Fix Version: 2.9.1, Resolution: Fixed - its done in 2.9.1, please
>>>> test.
>>>> Fix Version: 2.9.1, Resolution: Closed - its done in 2.9.1, its
>>>> tested, we are happy.
>>>>
>>>> There are thousands of issues. For someone to be able to group
>>>> all issues that they want to address for a particular version it
>>>> is nigh on impossible.
>>>>
>>>> The labels that we are currently using are too arbitrary IMO. I
>>>> could create a label '291fix' or '2.9.1fix' and they will be
>>>> completely separate.
>>>>
>>>> There used to be a field 'Target Version' (or mays thats just on
>>>> a local Jira instance), which is what you mention in your last
>>>> sentence and if you want to separate out the fields, that is the
>>>> way to go since it is a locked list of versions that you need to
>>>> choose from.
>>>>
>>>> cheers,
>>>> S
>>>>
>>>>
>>>> On 01/12/2012, at 2:53 AM, Matthew Jones <matthew at longsight.com
>>>> <mailto:matthew at longsight.com>> wrote:
>>>>
>>>>> I agree Jean-Francois, the fix versions is ambiguous. This was
>>>>> suggested on this jira ticket
>>>>> https://jira.atlassian.com/browse/JRA-22225
>>>>>
>>>>> The people in the core group treat the "Fix Version/s" field as
>>>>> being "Actual Fix Version/s" and should only be set by a branch
>>>>> manager or a developer who commits to trunk can set it as 2.10.
>>>>> If we notice that someone else has used this as an "Intended Fix
>>>>> Version/s" then I'll remove it and email them personally saying
>>>>> what the intention of this field is. For 2.9.1, we've used a
>>>>> label of 291triage as the workflow for Intended Fix Version.
>>>>>
>>>>> A little more reading lead me to seeing that we *could* download
>>>>> the translation pack, update the field "Fix Version/s" to
>>>>> something clearer, upload the pack and pick it as the default
>>>>> (https://translations.atlassian.com/). This would have to be
>>>>> done for every JIRA upgrade though, and probably take 15-30
>>>>> minutes. Perhaps this would be worthwhile if it reduces confusion?
>>>>>
>>>>> Additionally, rather than using the label, I we could create a
>>>>> custom version picker field where we could put in "Planned Fix
>>>>> Version/s". It looks like this was considered at one time and
>>>>> actually implemented in a few projects (Assignments2 and
>>>>> Gradebook2) but never in the CLE project. I think this is a good
>>>>> idea to do both of these things?
>>>>>
>>>>>
>>>>> On Fri, Nov 30, 2012 at 8:59 AM, Jean-Francois Leveque
>>>>> <jean-francois.leveque at upmc.fr
>>>>> <mailto:jean-francois.leveque at upmc.fr>> wrote:
>>>>>
>>>>> I have the feeling that there's sometimes a confusion
>>>>> between intended
>>>>> fix version and actual fix version in this field.
>>>>>
>>>>> I would prefer actual fix versions because they're less
>>>>> confusing and
>>>>> you wouldn't have to check other fields.
>>>>>
>>>>> Thanks,
>>>>> J-F
>>>>>
>>>>> On 30/11/2012 14:54, Neal Caidin wrote:
>>>>> > Okay, maybe I'll try deletes next time instead of merges
>>>>> and see if that works better. I get the sense that the
>>>>> fixVersion is not used consistently, but I'm not sure.
>>>>> >
>>>>> > Thanks,
>>>>> > Neal
>>>>> >
>>>>> > On Nov 29, 2012, at 6:57 PM, Beth
>>>>> Kirschner<bkirschn at umich.edu <mailto:bkirschn at umich.edu>> wrote:
>>>>> >
>>>>> >> Hi Neal,
>>>>> >>
>>>>> >> Comments below...
>>>>> >>
>>>>> >> - Beth
>>>>> >>
>>>>> >> On Nov 27, 2012, at 2:27 PM, Neal Caidin wrote:
>>>>> >>
>>>>> >>> Summary
>>>>> >>> --------------------
>>>>> >>> Done, mostly. All 2.9.0 alpha, beta, and rc versions
>>>>> merged into 2.9.0 and some cleanup per Matt's cleanup list
>>>>> (see below).
>>>>> >>>
>>>>> >>>
>>>>> >>> Notes
>>>>> >>> ---------------
>>>>> >>> * Side affect of merge is that there are over 800 issues
>>>>> for which at least one affectedVersion is 2.9.0 and at least
>>>>> one fixVersion is 2.9.0. Query : affectedVersion = "2.9.0"
>>>>> and fixVersion = "2.9.0"
>>>>> >>> * Only affected SAK, SAM, and KNL .
>>>>> >>> * wrt Resolved/Open/Awaiting issues having fix version
>>>>> unset,I may check with the Samigo team because they may be
>>>>> using the fixVersion in a slightly different way than the
>>>>> CLE release team overall.
>>>>> >>>
>>>>> >>> Questions
>>>>> >>> -----------------
>>>>> >>> * I don't see a way to bulk change the fixVersion in
>>>>> Jira. For those Jira admins out there, am I missing
>>>>> something? Many fields showed, but not fixVersion.
>>>>> >> If you delete a version, JIRA will offer you the option
>>>>> to bulk change all open JIRAs with an affectedVersion or
>>>>> fixVersion set to the soon to be deleted version. You're
>>>>> given the option of changing the version or leaving it
>>>>> blank. These are two separate questions, so you can change
>>>>> the affectedVersion to 2.9.0, and change the fixedVersion to
>>>>> nothing (which is what I'd suggest).
>>>>> >>
>>>>> >>> * Is it preferable to have an empty fixVersion or "2.10
>>>>> [tentative]" ? There are some issues that I'm hoping we will
>>>>> get into 2.9.2, and setting to "2.10 [tentative]" fix
>>>>> version seems wrong. On the other hand, we are only setting
>>>>> the fixVersion for the version in which the Jira is actually
>>>>> fixed, but maybe "2.10 [tentative] is a good place holder?
>>>>> >>>
>>>>> >> I think it's preferable to have an empty fixVersion -- we
>>>>> generally don't fill in that field until it's actually
>>>>> fixed. That makes querying easier, and it's also one less
>>>>> thing to change (and change again) as releases move forward.
>>>>> >>
>>>>> >>> Thanks,
>>>>> >>>
>>>>> >>>
>>>>> >>> Neal Caidin
>>>>> >>>
>>>>> >>> Sakai CLE Community Coordinator
>>>>> >>> nealcaidin at sakaifoundation.org
>>>>> <mailto:nealcaidin at sakaifoundation.org>
>>>>> >>> Skype: nealkdin
>>>>> >>> AIM: ncaidin at aol.com <mailto:ncaidin at aol.com>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> On Nov 19, 2012, at 4:15 PM, Matthew
>>>>> Jones<matthew at longsight.com <mailto:matthew at longsight.com>>
>>>>> wrote:
>>>>> >>>
>>>>> >>>> I'm good with this.
>>>>> >>>>
>>>>> >>>> Cleaning up the intermediary tags was also something I
>>>>> kept up on in the past:
>>>>> >>>>
>>>>> >>>> - All Verified or Resolved issues that *were* merged
>>>>> should be closed
>>>>> >>>> - All Resolved issues that were not merged (often
>>>>> because they weren't verified) should either be moved to the
>>>>> next release or have the fix version unset
>>>>> >>>> - All Open or Awaiting review issues should either have
>>>>> the fix version unset or moved to the next version
>>>>> >>>>
>>>>> >>>> Essentially the final release should just be all closed
>>>>> issues, so this is a decent amount of cleanup effort.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On Mon, Nov 19, 2012 at 4:04 PM, Beth
>>>>> Kirschner<bkirschn at umich.edu <mailto:bkirschn at umich.edu>> wrote:
>>>>> >>>> Hi Neal,
>>>>> >>>>
>>>>> >>>> One thing that Anthony has done in the past, following
>>>>> a release, was to remove all the JIRA alpha, beta&
>>>>> release-candidate tags, and consolidate them into one 2.9.0
>>>>> release. When you delete a version in JIRA, it offers you
>>>>> the option to change the deleted version to another version
>>>>> (e.g. 2.9.0). I think we should continue doing this so that
>>>>> the version list is less cluttered. Let me know if you'd
>>>>> like some off-line help on how to do this. Does anyone else
>>>>> think we should _not_ continue with this practice?
>>>>> >>>>
>>>>> >>>> - Beth
More information about the cle-release-team
mailing list