[sakai2-tcc] add Target version field in Jira?

Tue Mar 12 21:56:30 PDT 2013

I think the merge flags and (correct) fix versions are working ok as is.
It's just a case of knowing what versions of a tool are the ones that are
generally aligned with the Sakai 2.x.x release series.

So for Profile2 it is the 1.5.n releases that are generally made for Sakai
2.9.x. I wrote n because there could be any number of releases of this tool
for each Sakai 2.9.x release since its an indie and can be released off
cycle.

I understand the complexity about trying to find all issues across a large
number of projects all with different versions though. Keeping on top of
the various versions for the various tools is what is needed here, I think.
A label may help, but its just one extra bit of info that needs to be set.
When I resolve an issue I need to set the fix version, merge flag, and now
the correct label. Bit of a PITA, if a filter can just do the same thing
based on multiple projects and their fix versions.

cheers,
Steve

On Wed, Mar 13, 2013 at 3:26 PM, Noah Botimer <botimer at umich.edu> wrote:

> I have to refer to the old threads on Target Version, which was, indeed,
> tried with little success. This is not to say that it couldn't work, but
> rather than evidence that there is a better probability of that, I think we
> have the opposite. There are more versions, more components, more flags,
> and more projects in JIRA, all while there are fewer net hours going into
> "project management" (a.k.a. coordination) and keeping things synchronized.
>
> This is pretty easy to manage with the Fix Version field. Assigning and
> marking In Progress is also helpful. A simple heuristic may work here
> (though this may be a bit off):
>
> 1. Fix Version set to an unreleased version by some developer or someone
> who directs development speaks to a general commitment to finish something
> by that release. Unassigned here should imply a strategic priority with the
> TCC on board and seeking committed resource (if that sounds like it should
> be rare and a high bar, I agree -- this should be the emergency case).
>
> 2. Fix Version set to unreleased and marked In Progress signals active
> work to address an issue for said version.
>
> 3. Fix Version set to a release version while ticket is unresolved
> approaching release indicates a collision of intention and reality --
> contact needed, either to inform of a deadline or figure out time/help
> needed in the case of an essential fix.
>
> 4. Fix Version set to release version while ticket is unresolved after
> release indicates an incorrect ticket (finished, but unmarked) or a
> decision to release without said issue addressed (ticket incorrect by not
> reflecting decision) -- should be deferred one version if work is ongoing
> or imminent, or unset if resources never arrived or were redirected.
>
> Moving on to my usual "broader point"...
>
> We need to get over the impression and behavior that maintenance releases
> are momentus. Keeping everything on hold because we're "going to get a few
> more issues addressed soon" sets up almost infinite wait conditions in our
> pipeline. Slip begets slip, exception begets exception and everyone gets
> frustrated -- unless we are diligent to lock down either scope or schedule
> approaching releases.
>
> There'll be another release. Your fix will get picked up some time after
> it's done. No big deal. Any pressure should be about the nature of an
> issue, not artificial grandure of a release or uncertainty of schedule.
> It's surprising how effective a dependable release cycle and pattern is in
> helping to focus priorities and deliver to a plan rather than slipping on
> best intentions. A pattern of "just kidding, we're extending again" drives
> exactly the opposite, resulting in people not taking the schedule
> seriously, feeling futility of delivering fixes against artificial
> deadlines, and general ineffectiveness in a drawn out, nagging process.
>
> I think prospective release notes / changelog and a planned schedule, in
> one readable page go to the goals much more effectively than a Target field
> or any additional JIRA gymnastics. If the changelog is wrong, people will
> find and fix the info gathering process that made it wrong. Worst case, we
> have somewhat better information (by collation alone). Best case, we have
> great information people can use to plan local development and upgrades as
> well as understand and adjust community expectations on them.
>
> Remember, repeated execution is what makes a pattern work. I personally
> think the majority of our chaos comes from incrementally adding complexity
> rather than reducing it -- too little holds constant between cycles that
> are too far apart for us to establish anything that resembles a pattern.
>
> Thanks,
> -Noah
>
>
> P.S., I make no claim that I have not added complexity. I argued for
> adding Target Version years ago and made a few half-steps in cleaning up
> POMs for 2.9, both of which changed things but did not ultimately reduce
> our complexity or help us deliver quality releases on time. All of my
> current initiatives have a primary goal of reducing net complexity. I
> encourage everyone to focus on this kind of "community refactoring".
>
> On Mar 12, 2013, at 10:25 PM, Neal Caidin <nealcaidin at sakaifoundation.org>
> wrote:
>
> > I don't think the merge fields quite do the trick because they only
> indicate the merge intention to a branch, not to a particular tag. And I
> hypothesis, but of course could be very very wrong, that adding a target
> version will help, over time, the data to improve, because it will make the
> overall process clearer. While (thanks to your help) the processes and
> fields among the various projects are starting to converge, but they are
> still different and have different management processes in place (which
> makes sense to some extent, since that would be the idea of an Indie).
> >
> > -- Neal
> >
> > On Mar 12, 2013, at 10:17 PM, Aaron Zeckoski <azeckoski at unicon.net>
> wrote:
> >
> >> The merge fields already address this need in my opinion (at least for
> >> the CLE and KNL projects). Indies which use their own versioning are
> >> not really part of the same schedule so they shouldn't be using the
> >> same fields. We already have filters which use those fields and as far
> >> as I can tell they work.
> >>
> >> The fix version and affects version fields already tend to be wrong in
> >> many cases and adding another field is just going to me more wrong
> >> data.
> >> Maybe a better task would be fix up all the wrong fix and affects
> >> versions. After that is completed we can look at adding more fields
> >> and decide how we would maintain them accurately going forward.
> >>
> >> -AZ
> >>
> >>
> >> On Tue, Mar 12, 2013 at 10:09 PM, Neal Caidin
> >> <nealcaidin at sakaifoundation.org> wrote:
> >>> Hi TCC,
> >>>
> >>> This has come up before, recently I think, but I bring it up again
> because I think there is still a need. As I work on a query to cross
> projects for identify issues for qa testing, merging, etc, I still see an
> important use case of Jiras which it is not clear if they are intended for
> a particular release (2.9.2, for example), and after the fact, to identify
> issues that have been merged into the release (inconsistent use of fix
> version).
> >>>
> >>> Two possible strategies, both of which seem reasonable to me are:
> >>>
> >>> 1) Use of labels. The advantage of labels is that across the main
> project and indie projects we can use the same label to tie things together
> for a particular release, even with indies on different versions. One
> label, 292triage for example, can tie together disparate versioning
> conventions across MSGCNTR, LSNBLDR, BASICLTI, SAMIGO, etc. This should
> make it easier to do clean up on the fix version and help with queries for
> merging and testing (it did for me and the QA group in 2.9.1).
> >>>
> >>> OR
> >>>
> >>> 2) Add a Target version field in Jira, in addition to the affects
> version and fix version.  The advantage of a target version is that it will
> make it clearer which version an issue is intended to be included in
> (though extra translation may be needed to the overall release version) and
> it will also clear up confusion around the fix version, which many still
> use as a target version field.
> >>>
> >>> If you don't like either of these ideas do you have alternatives that
> might address these issues? If you are not convinced there is a need, I
> wonder how I can convince you? Hypnotism? Psychedilics? <just kidding!> You
> are feeling very sleepy. Oh, wait, that's me after a large dinner.
> Nevermind.
> >>>
> >>> Wondering if I should loop in QA and Dev groups. Folks in QA group
> definitely are with me on this issue, I would say.
> >>>
> >>> Cheers,
> >>> Neal
> >>>
> >>> _______________________________________________
> >>> sakai2-tcc mailing list
> >>> sakai2-tcc at collab.sakaiproject.org
> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> >>
> >>
> >>
> >> --
> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> >
> > _______________________________________________
> > sakai2-tcc mailing list
> > sakai2-tcc at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130313/a9548d7e/attachment.html 