Sounds sane to me.
Rogan Hamby, MLIS Data and Project Analyst Equinox Open Library Initiative phone: 1-877-OPEN-ILS (673-6457) email: ro...@equinoxinitiative.org web: http://EquinoxInitiative.org On Fri, Mar 30, 2018 at 10:35 AM, Bill Erickson <beric...@gmail.com> wrote: > 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 >>> >> >> >