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

[Rogan Hamby]

Sounds sane to me.


Rogan Hamby, MLIS

Data and Project Analyst

Equinox Open Library Initiative

phone:  1-877-OPEN-ILS (673-6457)

email:  rogan at EquinoxInitiative.org
web:  http://EquinoxInitiative.org

On Fri, Mar 30, 2018 at 10:35 AM, Bill Erickson <berickxx at gmail.com> wrote:

> 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/40ae7eef/attachment.html>