Hi, On Wed, Dec 18, 2013 at 8:49 AM, Paul Poulain <paul.poulain@biblibre.com> 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: gmc@esilibrary.com 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