Hi, On Wed, Dec 18, 2013 at 8:49 AM, Paul Poulain <[email protected]> wrote: > Le 10/12/2013 20:10, Chris Cormack a écrit : >> In theory this sounds good, with the caveat bug severity can override it >> too. > Agreed. > When I was RM (4 releases too, 2 with the current workflow ;-) ), I used > FIFO, except for BLO & CRI, which I was always dealing with 1st. > And that was easy because bugzilla display them in red !
To be explicit, and no doubt obvious: I don't use FIFO. Patches for security bugs, blockers, and criticals will take precedence, but I tend to mull over patches, and in some cases wait for other patches to pass QA so that a clump of patches on the same topic can be pushed. As I'm sure is obvious, I both reject a lot of patches and write a lot of follow-ups, including resolving merge conflicts. My primary emphasis is ensuring that regressions are minimized and that the new release will be as stable as possible. If I were to suggest one micro enhancement to to the process -- or perhaps just sing the same old tune -- if you want to increase the changes that your patch goes through signoff, QA review, and RM review quickly -- keep your patches small and focused and don't be afraid to split up large patches into series. As far as larger enhancements to the process -- the module maintainer project has been slow to get off the ground, but I'll be pushing more on it after the holidays. >> Of course we can make tons of suggestions, but it is really up to the RM >> how they use their time and we should be seeking to support them in what >> ultimately is a thankless role. > It's the RM final cut, but it does not mean all other must shut up & > just wait for another RM election (& candidate ;-) ) Indeed. Accountability is important to the process, and I agree that waiting for the next RM election is a bit long to wait. So, no need to shut up -- but also please remember that simply making complaints is not necessarily the most productive way to go about offering a critique. There are no robots involved in the process of signing off, QAing, or pushing patches (and keeping that in mind is why, if I had a *lot* more money, I would be organizing in-person global hackfests at least once every quarter). >> Speaking from my experience of RMing (4 releases I think) almost all you >> ever get is complaints. > In the short term, maybe. But in the long term ... look at your karma > Highest karma: "rangi" (962), "oleonard" (806), and "jcamins" (662) The IRC karma score is a bit of a game, and while I don't begrudge anybody that bit of fun, for various reasons I think it best that it not travel outside of #koha for risk of it being taken to seriously. There is a practice on the #code4lib channel that I think is a good one: each year, during the conference, karma scores are zeroed out. At the risk of derailing this thread -- I'm inclined to do that at the beginning of 2014. At Chris Cormack's request, I've zeroed his (and zeroed mine as well). Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: [email protected] direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
