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.



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!


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

Reply via email to