[OPEN-ILS-DEV] EG conference discussion topics

[Mike Rylander]

On Tue, Apr 19, 2011 at 11:57 AM, Galen Charlton <gmc at esilibrary.com> wrote:
> Hi,
>
> Here's a list of some development topics to discuss at the conference.  Some old, some new.  Please feel free to tack on.
>
> [1] DVCS (and Git, specifically)
>
> I think most active committers and developers are now using Git or Git+SVN, so IMO we're at the point where we can finalize this and come out of a conference with a decision, and perhaps even a completed-switch to Git.  Subtopics include:
>
> * confirming the DVCS to use - last chance for anybody with either an attachment to the status quo or a preference for any-DVCS-but-Git to make their case
> * planning the switch
> * managing repos - do we start a git.evergreen-ils.org, for example?
> * Git training/best practices discussion/cheatsheets
> * What does Signed-off-by mean, after all?

 * Who will update relevant documentation (How To Contribute, etc), by
when, and how, with (pass 1) factual changes and (pass 2) new best
practices.

> [2] Time-based releases
>
> Briefly, I propose that we switch to time-based releases.  In essence - every four months (for whatever value of "four" we feel best), we do a major release of Evergreen.  A feature doesn't make the deadline?  It'll have to wait, but that's OK: the next feature release is only four months away.
>

To help seed the discussion before we meet in person...

I've been thinking about this a lot recently (and a little for a lot
longer than recently) and I think the correct definition for "four" is
"six" (why that is, I think, is a topic for in-person, IMO).  The
release date can't the deadline in this plan, obviously.  The deadline
would be, say, ReleaseDate - X weeks (6? 8?), at which point we enter
for-real Beta for bug fixing on the target branch, and nothing else
goes into it.

(Side note, I think "four" is about the right definition of "four" for
2.1, and even 2.2, since there are major features queued up for both
already.)

> The motivations are:
>
> * Increasing predictability of releases.
> * Getting features out to users more quickly
> * Reducing the number of changes from release to release, thereby helping to make upgrades smoother
> * Hopefully smoothing out the workflow for DIG
>
> Related to this, Mike mentioned that a while back there was a discussion of a "stability" release schedule.  Although the notion of releasing candidates when they're stable, not at any particular date, may appear antithetical to time-based releases, the infrastructure needed to do stability releases (e.g., more automated testing, fully automated packaging, and more automation of upgrades) would also be necessary to do time-based releases well, and both have the aim of pushing more featurey goodness out more quickly.
>
> [3] Build and test infrastructure
>
> Obviously needed for time-based or stability release management.  Main subtopic: how to build on what Dan and others have built so far.
>

[4] Sketch a plan for creating more fault-tolerant upgrade SQL scripts

There's a lot of pain involved in upgrades when the SQL is largely a
single transaction and some of the things it wants to do are already
done in the target DB.  The 1.6-2.0 script is particularly painful in
this way.

One thought is to extend our current use of config.upgrade_log with a
function call instead of direct inserts, check if the chunk in
question is already applied, and if so then raise a notice saying as
much.  That would let us simply concatenate the Pg/upgrade/ dir into a
single script that applies what's in there, skips "we already have
that" exceptions, and will stop on errors encountered during one small
chunk so that it can be addressed manually.  Or, we could adopt the
upgrade_db.sh script used for dev environments, which does most of
this already ... but may be somewhat less robust than an all-in-db
version (or, it feels that way, a bit, to me).

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com