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

[Daniel Wells]

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/473ebb43/attachment.html>