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

[Bill Erickson]

I like it, Dan.  Thanks for the proposal.

-b

On Fri, Mar 30, 2018 at 10:08 AM, Terran McCanna <
tmccanna at georgialibraries.org> wrote:

> I think that's an excellent plan.
>
> Terran McCanna
> PINES Program Manager
> Georgia Public Library Service
> 1800 Century Place, Suite 150
> <https://maps.google.com/?q=1800+Century+Place,+Suite+150++Atlanta,+GA+30345&entry=gmail&source=g>
> Atlanta, GA 30345
> <https://maps.google.com/?q=1800+Century+Place,+Suite+150++Atlanta,+GA+30345&entry=gmail&source=g>
> 404-235-7138 <(404)%20235-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/63edad22/attachment-0001.html>