I like it, Dan. Thanks for the proposal. -b
On Fri, Mar 30, 2018 at 10:08 AM, Terran McCanna < tmcca...@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> > 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 >> > >