[cle-release-team] JIRA Version Maintenance
Jean-Francois Leveque
jean-francois.leveque at upmc.fr
Thu Dec 6 01:24:30 PST 2012
The issue is there are failures to the "When the issue actually gets
fixed then whoever does it should make sure the values are correct."
expectation.
J-F
On 05/12/2012 23:33, Steve Swinsburg wrote:
> 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