[WG: Sakai QA] [Building Sakai] 2x, JIRA use: When should maintenance branch should be in Fix Version/s?

[Noah Botimer]

So, I might alter my suggestion to say that we mark the earliest known version as Affects on a branch, in this case 2.6.0 (but as you say, in the case of regressions, it could be anywhere). I don't especially take anything but frustration from lots of versions being marked, but that could be personal.

Also, there are some triage concerns, where people reporting often only know the version they are on. How do we know whether an issue has been tracked as far forward or backward in time as needed by folks who have the technical abilities to do so? Comments don't work for filters.

I don't necessarily want to rekindle the whole conversation of ticket states, fields, and workflow, but do want to point out that we could still stand to polish our processes.

Thanks,
-Noah

On Jul 8, 2010, at 11:08 AM, Jean-Francois Leveque wrote:

> I suggest we do not reduce the affects to the latest, in order to avoid loosing information. Bugs can appear on a .1 release and still be in a .2 release without affecting a .0 release.
> 
> We cannot take for granted or not granted versions preceding 2.6.2 are affected when setting 2.6.2 in affects. We should explicitly at least add the versions we know are affected if they share the minor part like 2.6.? when we're still maintaining the 2.6 branch.
> 
> I think we should not keep 2.7.0 in affects when the official 2.7.0 is released and does not have the issue.
> 
> Noah Botimer a écrit :
>> It is important to have specific version numbers as much as possible. I think this applies even in the case where we are coming up on the end of the official support window for a maintenance branch -- marking a specific version that isn't released (yet or ever) indicates exactly where the fix is (on that branch, somewhere beyond the most recent release).
>> I guess I don't see the use of .x as a Fix version, ever, because it's not a version.
>> That ticket also shows a confusing pattern in Affects version:
>> *Affects Version/s:*	2.6.0, 2.6.1, 2.6.2, 2.7.0
>> *Fix Version/s:*	2.6.x <http://jira.sakaiproject.org/browse/SAK/fixforversion/11278>, 2.6.3 <http://jira.sakaiproject.org/browse/SAK/fixforversion/11670>, 2.7.0 <http://jira.sakaiproject.org/browse/SAK/fixforversion/11276>, 2.8.0 [Tentative] <http://jira.sakaiproject.org/browse/SAK/fixforversion/11671>
>> My suggestion would be that Affects should be only 2.6.2 and 2.7.0. Fix should be 2.6.3 and 2.7.0. This tracks the latest places it happens and the first places it's fixed.
>> Note that this ticket is a little special in that it was fixed in the 2.7.0 ramp-down, which means that it was getting eyes during the QA period and was altered by the post-release roll-up of the beta/rc versions (into 2.7.0). During that QA period, it was affecting a beta tag and fixed for another, giving critical information to the QA work. This roll-up is where the somewhat awkward construction of 2.7.0 in both fields comes from.
>> For anything past .0, this should never be the case, and we might consider stripping 2.7.0 from Affects version where the Fix is 2.7.0 as part of the beta/rc roll-up. Affects 2.6.2 and Fixed in 2.6.3/2.7.0 is pretty clear to me as an implementor because it tells me exactly when I'd be affected and what I can do to get the fix.
>> Thanks,
>> -Noah
>> On Jul 8, 2010, at 6:10 AM, Jean-Francois Leveque wrote:
>>> Hi all,
>>> 
>>> I think we shouldn't put maintenance branch in fix version most of the
>>> time. We should set fix version to the next release we intend to tag
>>> from the maintenance branch.
>>> 
>>> I think we only should do this when we're not tagging releases from the
>>> maintenance branch anymore.
>>> 
>>> WDYT?
>>> 
>>> My apologies to Jonathan Cook for using
>>> http://jira.sakaiproject.org/browse/SAK-18094 as an example, if you need
>>> one. You input is welcome, Jonathan.
>>> 
>>> --
>>> Jean-Francois
> 
>