Hi, On Wed, Dec 18, 2013 at 8:38 AM, Paul Poulain <paul.poul...@biblibre.com> wrote: > Le 10/12/2013 01:59, Galen Charlton a écrit : > I'd like to see as many of the 70 improvements or new features already > submitted by BibLibre (plus more coming) being signed-off, QAed and > pushed (Sorry if I appear a little bit rude) > > Same thing for the 120 improvements or new features not submitted by > BibLibre and that are in the same status.
I'll be direct: it is not enough to submit a patch, then expect it to be reviewed quickly. Eventually most things will get looked at by other developers in the community. "Eventually" is a rather imprecise time period, of course, and I appreciate how awkward it is. For good or ill, to my knowledge there's nobody who is time is being sponsored specifically to do patch review. We are quite fortunate that there are folks who are doing it anyway. I would like to publicly call out and thank the folks who have done 50 or more initial patch signoffs according to Bugzilla this year: Kyle M Hall- 262 Bernardo Gonzalez Kriegel- 192 Chris Cormack- 182 Owen Leonard- 177 Jonathan Druart- 112 M. de Rooy- 112 Srdjan Jankovic- 87 Katrin Fischer- 68 Paul Poulain- 63 Liz Rea- 50 I would also like to thank the folks who have reviewed any patches at all, too -- for the complete list so far, scroll to the bottom of the page at http://dashboard.koha-community.org/. Nonetheless, there needs to be more people signing off on things, period. However, I submit the following thesis: organizations -- and I use the word "organization" intentionally -- who author a lot of patches should also be doing a lot of patch review. More to the point, that patch review should be distributed, not just depend on the efforts of a subset of the developer employees.. That last sentence is yes, directed at BibLibre, but not just at BibLibre. There are several organizations active in Koha development who have more than one person authoring patches on a regular basis. Not all of them are reviewing patches at a proportional rate. Thus, my challenge to everybody, but in particular to multi-developer organizations: consider implementing a practice of *at least* one for one. In other words, for each patch you submit, review another developer's patch. Review doesn't mean automatic signoff -- it's valid feedback to mark a patch as failed QA so long as you explain why. If an organization has got an employee who is active on the QA team, their QA work counts too, of course -- but that shouldn't put the other developers of that organization off the hook for doing their share of patch review. One for one is a minimum, I feel -- there are several organizations that average two or more patches reviewed for each one they author. [2] One thing I will add -- if one looks at the commits pushed to the master branch, starting with the beginning of the 3.2 development cycle through the release of 3.14.0, the release manager who has pushed the most patches authored by BibLibre is... me. This isn't actually a terribly interesting fact, as a lot of factors contribute to the ebb and flow of which patches get pushed when, but I hope you will take this as indication that I highly value the work that BibLibre has done and continues to do. > > [1] Deprecation of the GRS-1 mode for Zebra. > +1 > > > Obstacles: the default UNIMARC indexing rules for the DOM filter need > > more testing. There is also an ongoing discussion about the desired > > semantics for the Any index, which at present behaves differently with > > the current DOM indexing rules as compared with GRS-1. > And BibLibre should be a leader here, I apologize because we aren't Great -- I look forward to BibLibre taking a more active role on this front. > > Upgrade considerations: in order to truly deprecate the GRS-1 filter, at > > some point there will have to be a forced reindexing upon upgrade. > Note that when upgrading from 3.6 to 3.8 (iirc), one also had to run a > separate script to remove items from marcxml, so having a "complex" > upgrade is "uncommon" but not "never happened" I agree -- a forced reindexing is by no means the end of the world in the simplest case: it just adds time to the upgrade process, but that can be planned for. Users who have customized their Zebra index definitions will have more work to do during an upgrade, however. > > [2] Use DBIx::Class to deploy the database schema for new installations. > No opinion, because I'm not sure I see all the consequences. Using DBIx::Class to deploy the schema would facilitate PostgreSQL support. Of more immediate interest, however, use of DBIx::Class::Schema::Versioned or the like to manage database updates would provide an alternative that doesn't rely on bespoke code. The primary obstacle to use of DBIC for deploying the schema is that DBIC doesn't inherently know anything about how to create indexes or which indexes to create. It also doesn't know anything about which MySQL storage engine to use. Fortunately, DBIC does provide a mechanism [1] for specifying the creation of indexes and setting per-table options, so the obstacle should be transient. > > [3] Relaunch PostgreSQL support > As a long term goal, I'm fine with that, but I don't think I'll invest > any time for now. Better adding DBIx::Class support imho. That's fine. [1] https://metacpan.org/pod/DBIx::Class::Schema#sqlt_deploy_hook [2] http://paste.koha-community.org/27 -- the report for 3.14.0 is courtesy of Chris Cormack. For each organization, the first line is the number of patches authored, while the second line is the number of patches containing a signoff from that organization. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: g...@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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
