I think that's an excellent plan. Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org
On Fri, Mar 30, 2018 at 10:00 AM, Daniel Wells <dbwe...@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 >