[cle-release-team] JIRA Version Maintenance
Jean-Francois Leveque
jean-francois.leveque at upmc.fr
Tue Dec 4 00:58:37 PST 2012
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