[OPEN-ILS-GENERAL] Proposed Change to LP Bug Tracking

[Terran McCanna]

I think that's an excellent plan.

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmccanna at georgialibraries.org


On Fri, Mar 30, 2018 at 10:00 AM, Daniel Wells <dbwells at gmail.com> wrote:

> Hello all,
>
> Our current practice is to only allow bugs to be targeted to a release
> only if there is code ready for testing.  This change was made several
> years back to help focus community efforts on testing of existing fixes,
> and also to avoid a lot of extra work in constantly moving huge numbers of
> bugs from milestone to milestone when no effort was being made to actually
> address them.  Overall, this change has worked as intended, and has greatly
> helped cases where branches would previously sit for months (or years)
> without inclusion into the shared codebase, or at least feedback.
>
> Unfortunately, this practice has also left a hole where some of our worst
> bugs are not getting the attention they deserve.  While we met our goal of
> satisfying all the "High" priority bugs targeted at 3.1 before final
> release, we currently have 25 other "High" priority bugs not targeted at
> any 3.1 milestone at all.  I am not sure how others work, but at least for
> me, as a release approaches, I am focused almost exclusively on the
> activity for bugs within the next release milestone, and it is therefore
> easy to lose track of important bugs where no branch has been offered (as
> those bugs, by current standards, remain untargeted).
>
> The natural solution, of course, is to target important bugs even before
> any solution exists.  (This does happen in some cases already.)  The
> challenge, then is to do this without again causing the issues we've faced
> in the past.  As stated, we currently have 25 such bugs, so it seems we
> aren't in imminent danger of a sudden deluge.  Still, I think we should
> have some modest standards to keep the bug flow reasonable and usable.
> With that in mind, here is a proposed starting point to work from:
>
> 1. Any bug with a status of "High" or "Critical" can be targeted to a
> milestone by the release manager/maintainer at any time.
> 2. Any High/Critical bug with at least 3 "affects me too" votes can be
> targeted to a milestone at any time by anyone.
> 3. A targeted High/Critical bug with no pullrequest is not a guarantee of
> inclusion the next release.  Timely releases are required for getting
> existing committed fixes to end users, so any delay for a High/Critical bug
> with no pullrequest will remain at the discretion of the release
> manager/maintainer.
>
> Overall, this is a very minor change, but given the cooperative nature of
> our community, there is little which can be done to actually force action
> on these bugs.  The goal, instead, is to make sure those responsible for
> releases are well aware of community needs, and also requiring us to at
> least confront any such bugs at each release time.
>
> Feedback is welcome!
>
> Sincerely,
> Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20180330/8e432a5a/attachment.html>