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

[Kathy Lussier]

I like this. It addresses the core issue of bring important bugs to the 
attention of developers without resuming a practice of retargeting the 
milestones of a bunch of lower-priority bugs that may never get fixed.

+1

Kathy


On 03/30/2018 10:00 AM, Daniel Wells 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

-- 
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
klussier at masslnc.org
Twitter: http://www.twitter.com/kmlussier