[Koha-devel] Architectural goals for 3.16

Wed Dec 18 23:31:12 CET 2013

Hi,

On Wed, Dec 18, 2013 at 8:38 AM, Paul Poulain <paul.poulain at 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:  gmc at 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