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
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier
