Hi, I propose to serve as Release Manager for Koha 3.14.0. My primary goals, if elected, are: 1. Continuing our tradition of solid, well-tested releases. 2. Experimenting with the structure of the release team to spread the work and knowledge around. 3. Dealing with and finalizing long-outstanding patches and feature requests 4. Broadening Koha's appeal and making it ready for a post-MARC world. I have the support of my employer to commit significant time to this role. Organization of the release team ----------------------------------------------- The Koha Release Manager has traditionally been the sole individual (at any given point in time) authorized to push patches to the master branch. This has given us some advantages: it allows for a unity of architectural vision, it gives us an additional level of patch review after the sign-off and QA process, and empowers to RM to push back on patches that are not quite ready for prime time. I also think that giving the RM a personal stake in the success and quality of a particular release provides good motivation. However, the unitary RM model also has some disadvantages. Having only one RM can contribute to a backlog of patches. It puts a lot of work and responsibility on one person, leading to the distinct possibility of RM burnout. And given the breadth of Koha's functionality, it's increasingly unlikely that any one individual can be equipped to personally test in depth each and every patch. To lay the groundwork for spreading the release work around, I intend to try the following experiments during my tenure as RM: 1. Naming module maintainers. By module maintainer, I mean somebody who is an expert in an area of functionality (e.g., reports) and who agrees to actively maintain a Git tree of vetted patches related to that module. If a module maintainer does a good job, it opens up the possibility of the RM being able to pull it a group of branches from the maintainer's tree in one fell swoop, confident that the module maintainer has thoroughly tested it. Over time, it might be possible that a trusted module maintainer would get authorization to push patches for their module directly to master. 2. Naming master branch committers. These would be folks who share in the day-to-day work of reviewing QAed patches and pushing them to master. Committers would be expected to use their best judgment when applying patches, but also to follow guidelines discussed by the current RM and the Koha development community as whole. In time, this model might evolve to one where the release manager is just a named "first among equals" among the master branch committers whose primary responsibility is to be a final decision-maker in the case of dispute. These experiments may or may not work, but with any luck during 3.14 we will succeed in laying some groundwork for the release management load to be shared. If any folks are interested in becoming a module maintainer, please let me know. Major architectural and feature goals ----------------------------------------------------- My primary goal for 3.14 will be to significantly reduce the backlog of patches that has accumulated over the past few years. However, I also have some specific architectural goals: 1. Improve sharing of code with other projects. In particular, I'd like fold Koha's custom fork of SIPServer back into the standalone SIPServer project, and work with packages to have SIPServer become available as a stand-alone package. Another project I'd like to at least start is folding in the MFHD-handling code from Evergreen and spinning that out of as an indepdent Perl module. 2. Building on the Solr and Zebra DOM work and efforts to rewrite the search-subsystem, with the goal of having true pluggable search backend support in 3.14.0. 3. Adding support for non-MARC metadata. Communication ---------------------- I will continue to practice of a writing a monthly RM newsletter to be sent out via email to the mailing lists. I will also do a (roughly) weekly RM summary blog. To help encourage the spread of knowledge about the mechanics of performing the RM and RMaint roles, I also intend to do targeted blog posts and/or videos going into some depth. Examples of topics I might present include: * How to resolve a merge conflict. * Techniques for managing large topic branches. * A video showing the mechanics of cutting a release tarball. Timeline ------------ I propose the following general timeline: * 23 May 2013: we start (blearily) the push to 3.14.0 * 30 August 2013: release of pre-pre-alpha 3.14 - after this point, major architectural changes will be discouraged * 25 September 2013: feature slush * 3 October 2013: feature freeze * 31 October 2013: string freeze * 21 November 2013: release of 3.14.0 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
Le 12/03/2013 18:11, Galen Charlton a écrit :
To lay the groundwork for spreading the release work around, I intend to try the following experiments during my tenure as RM:
1. Naming module maintainers. +1 Over time, it might be possible that a trusted module maintainer would get authorization to push patches for their module directly to master. +10. Spreading responsibilities is really an improvement imo!
2. Naming master branch committers. +10
In time, this model might evolve to one where the release manager is just a named "first among equals" among the master branch committers whose primary responsibility is to be a final decision-maker in the case of dispute. Well, you can't be "first among equals" because you're not from Constantinople AFAIK (see http://en.wikipedia.org/wiki/Primus_inter_pares#Eastern_Orthodox_Church) ;-) (kidding)
These experiments may or may not work, but with any luck during 3.14 we will succeed in laying some groundwork for the release management load to be shared. I hope it will work ! And if it does not work because of lack of volunteers, it does not mean it must be abandoned in the next release. This announcement/proposal is a little bit late for us (BibLibre), but I'll try to see if someone want to jump into a role.
If any folks are interested in becoming a module maintainer, please let me know. will do ;-)
My primary goal for 3.14 will be to significantly reduce the backlog of patches that has accumulated over the past few years. Good luck, you've all my encouragements (sincerely). How do you plan to do that ? Do you have already an idea ?
2. Building on the Solr and Zebra DOM work and efforts to rewrite the search-subsystem, with the goal of having true pluggable search backend support in 3.14.0. +10
3. Adding support for non-MARC metadata. +10 (same qustion as previously = do you have an idea how you'll do that ?
One of my concern atm, is to investigate how to improve performances and reduce load. I'll try to spend some time on that during next week hackfest. PS: I can't be at the meeting, and it's a shame. However, the votes shouldn't be a problem, as we don't have too much volunteers (as usual...) PS2: I haven't QAed a lot of patches in the last months. I hope that things will be better for the next release... -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation
In short: Great proposal, Galen. +1 for module maintainers, -1 for master branch committers :) To be explained:
2. Experimenting with the structure of the release team to spread the work and knowledge around. I would not favor too much experimenting here for continuity.. We should not change workflow every other release (or new RM).
Instead of forming a new group of master branch committers, I think that the RM should only push patches. But he should be allowed to delegate his responsibility of checking a patch to a module maintainer. A second signoff from the module maintainer could lighten the load for QA and RM. If some module maintainers would be part of the QA team, that would be even better. Note that the workload for QA was made higher during the last release, proven by a growing signed-off-queue. Instead of more master branch committers making final decisions, the QAer could/should ask for more feedback (from fellow QAers and module maintainers) during the process when some patch raises doubts. If the RM still doubts after that, my idea should be: ask the community by mailing the dev list. (These cases should be exceptional.) Marcel
2. Experimenting with the structure of the release team to spread the work and knowledge around. I would not favor too much experimenting here for continuity.. We should not change workflow every other release (or new RM). well, OTOH, we're a small community, so it's good to refine the workflow from time to time. I think it hasn't been changed since 3.4, except for the "RM can QA"
Instead of forming a new group of master branch committers, I think that the RM should only push patches. But he should be allowed to delegate his responsibility of checking a patch to a module maintainer. A second signoff from the module maintainer could lighten the load for QA and RM. If some module maintainers would be part of
Le 13/03/2013 13:28, Marcel de Rooy a écrit : that had been decided when I was RM, I used it a lot, and I think Jared didn't. Jared also added the rule "QA must sign-off the patch on bugzilla", which is not a big change. the QA team, that would be even
better. Note that the workload for QA was made higher during the last release, proven by a growing signed-off-queue.
My main comment here is that a patch validated must be very quickly pushed, otherwise, before pushing, it's always required to test it. Because there can be some nasty side effect added by another patch that has been pushed in the meantime. That's why I like the idea of branch commiters. Of course there should not be such commiters on core features (like circulation), but for things like tools, reports, admin or maybe even patron management, I think it's a good idea : it would reduce the load of the RM, that could concentrate on other things. HTH -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation
On Tue, Mar 12, 2013 at 1:11 PM, Galen Charlton <gmc@esilibrary.com> wrote:
If any folks are interested in becoming a module maintainer, please let me know.
I would be willing to volunteer as a module maintainer for plugins, holds, fines, and/or course reserves ( once it is pushed ). Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
participants (4)
-
Galen Charlton -
Kyle Hall -
Marcel de Rooy -
Paul Poulain