[cle-release-team] JIRA Version Maintenance
Neal Caidin
nealcaidin at sakaifoundation.org
Tue Dec 11 05:47:52 PST 2012
There are about 370 issues which have 2.9.0 as a fix version and are not closed.
Out of those there are only 2 with the 2.9.x status in Resolved (code has been merged).
Not sure how much of the side affect was caused by merging all the different 2.9.0 alpha, beta and rc versions, but conceptually that should not make a difference. In fact, what is the meaning of a fix version of alpha, beta, or rc, unless one expects some kind of merge for a "real" fix version?
-- Neal
On Dec 6, 2012, at 4:24 AM, Jean-Francois Leveque <jean-francois.leveque at upmc.fr> wrote:
> 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
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
More information about the cle-release-team
mailing list