[OPEN-ILS-DEV] SPAM Re: SPAM Re: Well, it's that time again ...

Wed Apr 7 10:01:54 EDT 2010

Hi Mike, Dan, and all,

I just wanted to chime in about this:

> More generally, while I'm thinking about it (and you touch on it
> below), we haven't discussed EOLing release streams outright ... they
> just kind of die.  I think we should state a general policy, and I
> would propose that policy to be something like:
> 
> We will make every effort to maintain bug fix releases for the
> highest minor revision on the newest major revision, until that
> stream is no longer the immediately previous major revision.

As a representative of an "end user agency,"  I think the more we could know about the Evergreen developers' plans to phase out support for releases (or entire branches) the better.  Would you/the community developers consider setting dates, say, 90 days out (minimum) from when you plan to cease supporting, backporting, bugfixing, etc.?  It would help us plan our testing/implementation cycles to know dates for this kind of thing ahead of time.

Thanks,
Chris

Chris Sharp
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, Georgia 30345
(404) 235-7147
csharp at georgialibraries.org
http://pines.georgialibraries.org/

----- "Mike Rylander" <mrylander at gmail.com> wrote:

> On Tue, Apr 6, 2010 at 4:29 PM, Dan Scott <dan at coffeecode.net> wrote:
> > On Tue, 2010-04-06 at 11:25 -0400, Mike Rylander wrote:
> 
> [snip]
> 
> >>  * 1.6.1.0 -- Big-ish feature release, specifically
> >> Booking/Reservation, along with all the fixes in 1.6.0.4.  This,
> too,
> >> is nearly ready, but there is at least one pointy bit in the code
> to
> >> smooth out (op-capture delay of temporally distant reservations --
> we
> >> have a plan), and the matching documentation (I know!  Can you
> believe
> >> it?!) needs to be brought up to speed.  That's planned for (more
> or
> >> less) next week.  Realistic target for this, right now, seems like
> May
> >> 15.
> >
> > The self-serve password reset interface should be usable in this
> > release, too, particularly given a May 15 time frame.
> 
> I didn't realize you were targetting 1.6.1 -- I hadn't been following
> the commits closely.  Cool!
> 
> >
> >> Beyond that things get fuzzier, but there's more to plan.
> >>
> >> So, we have trunk, which will become something-after-1.6.  I
> propose,
> >> because of the massive changes in both code and database
> structure,
> >> that we use the version number to help convey that this is largely
> new
> >> code and call it 2.0 when it's branched.  Also, in addition to the
> >> newness of the code and the DB changes, there's the fact that 1.6
> has
> >> only been around for about 6 months.  Originally, 1.6 was going to
> be
> >> a short-lived stepping stone on the way to
> >> whatever-contained-acquisition.0, but it's taken on a life of it's
> own
> >> and is both divergent /and/ mature enough that we can reasonably
> >> expect some sites to stay on 1.6.something for a while.  As for a
> >> target date on this, well, an alpha look probable by August.
> >>
> >> Which brings us to the possibility of a 1.6.2 series.  IMO, it
> would
> >> be worth considering a few trunk-only features for backporting to
> this
> >> hypothetical release stream.  For instance, if serials can
> reasonably
> >> be extracted intact, that would be a top contender in my mind.
> >
> > I think serials support is already in 1.6.0.3 - unless there's
> something
> > I'm not aware of? (Entirely possible).
> >
> 
> There's the stuff you put in, but in order to make serials work with
> Acq, and make items circulate using the issuance backend that we've
> been dreaming of, a ton more will be coming.  Dan Wells, expect a lot
> of discussion soon on your proposed schema! (
> http://open-ils.org/dokuwiki/doku.php?do=revisions&id=acq:serials:basic_predicting_and_receiving
> )
> 
> IOW, I'm thinking of the
> subscription/distribution/issuance/shelving-unit stuff, in addition
> to
> the (quite excellent) MFHD functionality.
> 
> >> Another would be the advances we've made with Action/Trigger that
> >> allow much more sophisticated setups and more intelligent, not to
> >> mention faster, processing of events.  A third example might be
> some
> >> of the Staff Client improvements, most likely the Circulation and
> >> Cataloging related changes, that are in trunk now or going into
> trunk
> >> over the next couple months.  That could make 1.6.2 a true
> stepping
> >> stone to 2.x, and give us the change to put some of the more often
> >> requested features (but not ACQ) into the field for real-world
> >> shakedown.  I wouldn't expect this until some time after the
> 2.0-alpha
> >> (or maybe even the 2.0.0.0 GA release) as we shouldn't let it
> drain
> >> resources from 2.0, but before the end of the year would be my
> hope.
> >
> > If it's a stepping stone to 2.0, why not call it 1.8 and make that
> > clear?
> 
> It /could/ be ... it depends on what can be backported, and if anyone
> steps up to do the backporting (other than someone being contracted
> to
> do it).  If the backporting were community work, and started as soon
> as 1.6.1 dropped, then it would be release whenever it was done.  As
> far as scheduling goes, I'm just talking about what I can directly
> control and attribute in terms of resources.  And, in the case of
> 1.6.2, that's not much right now with 2.0 and 1.6.1 and FulfILLment
> going on concurrently. ;)
> 
> But, why not call it 1.8?  Because then we'd be releasing 1.8 (a big
> conceptual jump from 1.6) after (or nearly coincident with) 2.0,
> which
> seems stranger to me than extending 1.6 as an existing stream by
> adding new features from a forward branch.  From a maintenance
> perspective, it would mean three open major revision (2.0, 1.8, 1.6)
> branches instead of two (2.0, 1.6).  While, by all accounts, almost
> everyone that is considering Evergreen but not yet using it is indeed
> waiting on what will be in 2.0, there are plenty of current users for
> whom 1.6.something-or-other will be viable for the foreseeable
> future.
> 
> More generally, while I'm thinking about it (and you touch on it
> below), we haven't discussed EOLing release streams outright ... they
> just kind of die.  I think we should state a general policy, and I
> would propose that policy to be something like:
> 
>   We will make every effort to maintain bug fix releases for the
> highest minor revision on the newest major revision, until that
> stream
> is no longer the immediately previous major revision.
> 
> Clear as mud, right?  For example, if a major bug was discovered in
> 1.4.0 today, and a fix was both reasonable to implement in terms of
> effort /and/ safer for most 1.4 users than the risk of upgrading to
> 1.6.0.newest, then I'd be in favor of creating a bugfix release
> (1.4.0.8).  However, as soon as 2.0 is cut, 1.4 is dead (just like
> 1.2
> is dead (by attrition and convention) now that 1.6 is out).  But that
> doesn't mean that we couldn't (if there were a strong reason to)
> release 1.4.1.0 right now.  Then 1.4.0 would be dead, and 1.4.1 would
> be the branch to receive bug fixes.
> 
> Because the jump from 1.6 to 2.0 will be so huge, and a great deal of
> the code in 2.0 will be immature at the start of the 2.0 stream, it
> seems reasonable to me to expect many users to want to stay on 1.6
> for
> a while.  If some features present themselves as good backporting
> candidates then we should make an effort to extend 1.6.  My proposed
> list is entirely hypothetical, of course, but just what I see right
> now.  Serials beyond straight MFHD may well be untenable to backport,
> but A/T enhancements probably aren't, for instance, and for users of
> 1.6 today that would be a big win.  (And as a side note, if we want
> to
> get 1.6.1 out, which I certainly do, then anything not in cleanup
> mode
> today needs to wait.)
> 
> > The differences between your proposed 1.6.2 and 1.6.1 seem much
> > larger than the differences between 1.6.1 and 1.6.0
> 
> To be fair, the Booking Reservation work is probably bigger than any
> two in combination of the above mentioned three possibilities.  It's
> "just one feature" but the impact on the code is very broad.
> 
> > , and the only reason
> > I can think of to call it 1.6.2 is to provide some justification for
> the
> > continued usage of an x.y.z.A release naming scheme :)
> >
> 
> Well, to be frank, I think we /should/ continue using that scheme*.
> It provides a clear frame of reference (at least to me) about what
> can
> go where, and when.  The way I describe the scheme is:
> {world-altering-changes}.{requires-a-new-staff-client-changes}.{new-minor-feature-changes}.{bug-fixes}.
>  To put more traditional labels on the components:
> {version}.{major-revision}.{minor-revision}.{release}
> 
> But that's not my reasoning -- I consider the naming scheme a
> feature.
>  My reasoning is just up ^ there.
> 
> 
> * Now, all that being said, if someone were to take on the project of
> actually setting up a CI system (ESI would be happy to host the
> buildbot again or toss up a server for something else, but, as time
> and resources stand now, bootstrapping that is something that others
> will need to put some muscle behind) then I'd be happy to toss
> version
> numbers out the window and start stamping test-passing,
> consensus-gaining nightly builds as releases as soon as they're
> ready,
> as we discussed last year.
> 
> >> So ... Thoughts?
> >>
> >
> > I worry a bit about how many branches we (the relatively limited
> > community of developers) will have to actively maintain at a time.
> Let's
> > assume we push out a 1.6.2 release - would we be expected to
> backport
> > those fixes to 1.6.1, 1.6.0, 1.4.0...? And more importantly, test
> those
> > fixes to ensure that no regressions are introduced, in all of those
> > branches?
> >
> 
> I agree with that worry ... that's why I'm (tangentially) proposing a
> general EOLing rule of supporting, from a community perspective, the
> newest minor revision of the immediately previous major revision for
> any bug fixes.  That leaves us, effectively, where we are today.  We
> have trunk, rel_1_6, rel_1_6_X (soon to move from 0 to 1), and for
> severe data-loss bugs, rel_1_4_{newest}.  When 2.0 is released we'll
> have trunk, rel_2_0, rel_2_0_0 and rel_1_6_{newest}.
> 
> > Let's review our release history:
> > * September 2006: 1.0 is released (yay!)
> > * October 2007: 1.2.0 is released - 13 months
> > * November 2007: 1.2.1 is released - 1 month
> > * May 2008: 1.2.2 is released - 6 months
> > * January 2009: 1.4.0 is released - 7 months
> > * November 2009: 1.6.0 is released - 10 months
> > * May 2010: 1.6.2 (proposed) - 6 months
> >
> 
> You mean 1.6.1, I assume.
> 
> > I'm not sure we have any project commitments to how many release
> > branches we support at a given time, but from the current downloads
> > directory it looks like two: 1.6 and 1.4. Given the pace of our
> major
> > releases, I suggest we jump directly to 1.7 instead of 1.6.1 - then
> the
> > two supported branches would become 1.7.x and 1.6.x, until 1.8 is
> > released. At our current pace of one major release every seven or
> eight
> > months (with 1.2.0/1.2.1 an anomaly), this would give a library a
> little
> > over a year of bug fixes on a given major release before they would
> have
> > to make a more significant upgrade to continue to receive bug
> fixes.
> >
> 
> I think we're trying to get to basically the same place, we just seem
> to disagree on the utility of the 4-number scheme.
> 
> > Perhaps as a development community, we could commit to supporting a
> > major release for a minimum of 1 year if our development pace
> increases
> > and new features start rolling in? Of course, the support periods
> > offered by the community vs. those offered by a given support vendor
> can
> > and probably should differ. Anyways, it's just a thought, and
> possibly a
> > completely unworkable one if we were to move to a development model
> of
> > more frequent releases with smaller deltas that included the
> > slipstreaming of new features, rather than less frequent feature
> > releases with correspondingly bulkier deltas that are more likely
> to
> > introduce unexpected side-effects (the "Augh! It's the only feature
> > release this year, so I've got to cram in my almost-finished
> feature
> > even though it's not all that tested because otherwise I'll need to
> wait
> > until next year..." syndrome).
> >
> 
> Another vote for 1.6.2, IMO. ;)
> 
> > On the OpenSRF side, Scott has put in a massive amount of work
> > refactoring and optimizing the OpenSRF and Evergreen C code. I had
> > suggested a 1.4.0 beta of OpenSRF at our last development meeting
> >
> (http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2009-12:minutes)
> and received some support for the idea - there's OpenSRF code that
> hasn't seen the light of even an alpha release for 8 months now.
> >
> 
> I'm all for someone picking up the release torch, particularly for
> OpenSRF.  OpenSRF is super-easy to cut a release for, especially
> compared to Evergreen, and I'd support getting the code out there,
> too.  I just don't have the time until I'm pressed by an Evergreen
> dependency.
> 
> > As for 2.0 and major infrastructure changes, part of my motivation
> > (personal and employment-related) is working on things that make an
> > immediate difference to Evergreen sites. I'm therefore trying to
> figure
> > out where to invest my time.
> 
> To me, that's even more reason to consider a 1.6.2 release targetting
> some trunk features that could be (relatively easily) backported and
> get to see the light of day sooner.  IMO, /that/ would be a great
> place to focus in order to make an immediate difference.  If someone
> were to pull, say, A/T enhancements and telephony from trunk into 1.6
> after 1.6.1 dropped, I'd consider that enough to warrant a 1.6.2,
> personally.
> 
> > If something isn't expected to land in a
> > real release until 2011 - even if it is Really Cool(TM) like in-db
> > ingest and kick-butt indexing & query parsing - then I'm probably
> going
> > to focus on a different problem, or attack the problem using the
> > currently available infrastructure, rather than worrying about
> something
> > in trunk that still might change dramatically in six months time
> before
> > it ever sees the light of day.
> >
> 
> Your examples will be in the 2.0 alpha targetting August 2010
> (twenty-ten, no typo) which will come from trunk.  It'll be in use by
> at least one site come this September.  There will be plenty of work
> to do to call it 2.0.0.0, but it will be based on real-world use of
> the system.  But, even then, if you're basing new features off of 1.6
> that require integration with infrastructure that is new, enhanced or
> replaced in trunk, forward-porting will probably be harder than
> backporting in most cases, and just as hard in the others.  See Also:
> Booking ... :(
> 
> > Thanks for opening up this discussion, Mike; I know you probably
> cringe
> > in anticipation of my response :)
> 
> Cringe isn't the right word ... ;)
> 
> -- 
> Mike Rylander
>  | VP, Research and Design
>  | Equinox Software, Inc. / The Evergreen Experts
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  miker at esilibrary.com
>  | web:  http://www.esilibrary.com

[OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Re: Well, it's that time again ...

[OPEN-ILS-DEV] SPAM Re: SPAM Re: Well, it's that time again ...