[cle-release-team] JIRA Version Maintenance

[Matthew Jones]

I do think the whole thing with jira as well as releases and the
"paperwork" involved takes up way too much time from people that could be
doing actual work, which is why we keep ending up here. ;) The ability to
resolve issues (and set the fix version) is already limited to a select
number of groups. Maybe those groups just need to be cleaned up more and
people need to be better informed about the information already published.

I'm mostly convinced that this doesn't need any alteration but a it would
be nicer if they made a label change easier.

I was reading recently that 40% of a scientists research time goes
to bureaucratic work, leaving 60% for actual work. This is what this feels
like. ;) [1]

[1] http://www.scientificamerican.com/article.cfm?id=dr-no-money



On Mon, Dec 3, 2012 at 5:58 PM, Noah Botimer <botimer at umich.edu> wrote:

> TL;DR - I probably wouldn't elect for the maintenance effort, but a slight
> label change on the Fix Version field is as far as I would go in up-ending
> the workflow, and maybe decide for 2.10 that we roll-up to 2.10-prerelease
> instead of 2.10.0.
>
> ---
>
> I think this is all bound to remain a fuzzy reality needing periodic
> housekeeping more than periodic reengineering.
>
> We've moved around slightly in our language and practice for about three
> years but keep settling here. The experiments with a Target Version field,
> merge status fields vs. subtasks vs. linked issues, and others have been
> run. What we're doing is either right or we don't have enough consensus and
> commitment to an alternative. I personally don't have the energy to try to
> come up with and enforce new rules and behavior because time and again,
> that has proven to put roadblocks in front of our contributors without much
> upside -- we go into some different-but-equivalent state of acceptably mild
> chaos.
>
> The Fix Version is likely to remain like the "In Progress" state --
> occasionally used before an issue is resolved to indicate intent or
> activity. I don't think it's detrimental unless we shoot for something
> absolute and make meaning of it, which is bound to be disappointing. The
> thing that matters is that we have a way to indicate that something is A)
> needing attention B) as done a developer thinks it needs to be for testing,
> C) tested and accepted or rejected, D) merged into all the places we think
> it should be.
>
> The rest is details and subject to some volatility. If we keep the
> authoritative statements to a minimal set (like: when something is marked
> closed, it's done done; if it's not closed, there is work to do), we have
> fewer things to see as out of place. There is plenty of known, clearly
> marked work to do, and completing it surfaces the remaining oddballs.
>
> I think this conversation started with the edge case of pre-release
> roll-up into 2.9.0. Again, I don't think having affected/fixed as the same
> version is a problem for an x.0 release. If others do, rolling into one
> 2.x.0-pre version would catch these. It's a question of what the combo of
> affects/fix is expressing and whether it being the same is simply
> unacceptable. These are new issues that arose somewhere beyond 2.8 and
> before 2.9. In general, there is a release where something is noticed, so
> the "rule" of affects != fix applies, but these don't have a "noticed in"
> release. We have to decide how much effort needs to go into clarifying
> something that happens once a year at best, under known circumstances, and
> is "just a little weird".
>
> Food for thought -- what happens when a fix we want to keep introduces an
> oddity or regression that we notice later and also fix for an upcoming
> release? Would that be, for example, affects = 2.9.1 and fixed = 2.9.1,
> since the oddity is not in 2.9.0? I tend to think it can be meaningful in
> special cases and it's just not that big of a deal to have the same value
> in both fields.
>
> Thanks,
> -Noah
>
> On Dec 3, 2012, at 5:05 PM, Matthew Jones wrote:
>
> I think perhaps those are perfect world JIRA guidelines.
>
> In realistic world many people submit tickets with no development
> resources were setting the fix version hoping that some developer would
> come along to fix it. So maybe that's the problem, people who set it it
> when they create a ticket without any intention of actually fixing the
> ticket? Realistically issues lately only get fixed if:
> - The ticket is a blocker
> - The ticket has come up locally for some SCA's customer or educational
> institution with development resources
> - The ticket is in a select project with a team like Lessons or Samigo
>
> A developer often does know when it's going to get fixed after they've
> fixed it or when they'll work on it. Certainly someone random who wants
> something done done with no development staff can't make that decision.
>
> Also, none of the teams have dedicated QA or Branch Management resources.
> QA and Release Management completely volunteer so that *could* and often
> does hold up non blocker issues from getting in. Sometimes Resolved->Fixed
> issues get tested in time for the release, sometimes they don't. Sometimes
> Verified->Fixed issues get merged in time for the release, sometimes they
> don't.
>
> It's possible we could have Neal as the only non-volunteer be involved in
> some cleanup activity for the issues that don't get tested or merged after
> release.
>
>
> On Mon, Dec 3, 2012 at 4:52 PM, Steve Swinsburg <steve.swinsburg at gmail.com
> > 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> 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> 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
>>>
>>> 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>
>>> 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> 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> 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
>>>> >
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20121203/2ce96a37/attachment-0006.html