[Koha-devel] Commentary on Paul's Koha 3.8 Release Manager proposal

Mon Sep 12 15:37:13 CEST 2011

Paul,

Yes, the main difference in our proposals is primarily one of timing.
You're proposing that we have Koha 4.0 ready in about 1 year, and will
include Solr integration and updated Perl coding practices.  Those are
certainly good things, yes, and they may well be possible in 1 year.  Or
they may not.

I agree that we should continue to do time-based releases; every 6 months
seems to be working well for us.  The difficulty here, though, is that with
time-based releases, you cannot guarantee that any given feature will be
ready in time.  Sure, any one development team can promise they'll have it
coded up to their clients standards and rebased for inclusion, but how will
that interact with other code written by other teams?  Who, outside the
original development team, can be committed to test and sign-off on the
work?

So, when working on time-based releases, you cannot promise features.  This
is why I propose we continue with time-based releases on the 3.X line until
such time as all the agreed-upon features for Koha 4.0 are ready.  If we're
quick, sure, we can jump straight from 3.8 to 4.0.  I think it's much more
likely we'll have a 3.10 in there, but maybe that's just me.

By no longer attempting to set a release date for a feature-based release,
we open ourselves up to more feature possibilities for Koha 4.0.  Solr and
updated Perl pratices are both very developer-centric improvements.  What
are the positive end results for the libraries?  I know with Solr, you can
more easily customize your facets.  Updated Perl coding could result in
faster performance.  I think it's more important to define our goals in
those terms, rather than in how we're going to accomplish them.

HDL pointed out early in the thread that some of the features I was floating
as possible for Koha 4.0 were librarian-centric, and some were
developer-centric.  He's right, I wasn't really clearly differentiating in
that list.  It was mostly meant as an example of what else would could
reasonably accomplish for the next major release of the software.

I don't think there will be nearly as many merge conflicts and rebase issues
as you fear, Paul.  Once we decide on our feature set, any interested
developers would meet to figure out the coding requirements.  This may take
several meetings, but in the end, we'll have a roadmap of what features
depend on what. A couple points of practice will make the development go
more smoothly:

   - Those that can be done first will be, which will then open the door for
   other features, and so on.
   - Developments for each feature are done on frequently-rebased topic
   branches.  Since we'll have identified them as a community, we can put them
   on the main Koha git repo.  We can give keys on a per-branch basis to the
   developers working most heavily on those branches.
   - Small, atomic, easily-tested patches are the key here.  If two features
   can both be developed concurrently, and they happen to tread on each others
   toes, this will keep any merge conflicts small and easily reconciled.

Whatever features are ready by the feature freeze for 3.8 would be what go
into 3.8; this is a matter of distribution and labeling, and won't affect
the developers who are all working on master (or it's closely-based feature
branches).  Release Maintainers will continue their job backporting fixes to
those stable branches we still support.

I really like the idea of having multiple sandboxes set up so that folks can
test the different features more easily.  We should definitely do this.
Having more people doing testing and Quality Assurance is always a good
thing.  Providing test plans, test results and reasons for passing/failing
QA on the bug report will make it much easier to keep track of the history
of any particular fix or feature.

Our end goal is the same:  make Koha the best it can be.  We're mostly
disagreeing over small details.  Whatever the outcome of this discussion, I
know we will all continue to work hard together to improve Koha.

Cheers,

-Ian

On Mon, Sep 12, 2011 at 5:33 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 07/09/2011 23:58, Ian Walls a écrit :
> > Everyone,
> Hi Ian & everyone,
> > The major disagreement is with the timeline.  The proposal as it
> > stands is to start working on Koha 3.8 and Koha 4.0 in parallel, with
> > Koha 3.8 releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I
> > feel that going from Koha 3.8 directly to 4.0 is unwarranted.  To my
> > mind, there are many possible releases between 3.8 and 4.0, like 3.10,
> > 3.12, 3.14 and so forth.  This is supported by the actual database
> > version numbers in Koha: the current release is actually 3.04.04; the
> > zeros are squashed out for convenience.
> I think our main (only ?) disagreement is based on some
> misunderstandings. I'll try to explain more clearly.
>
> Here is the timeline for Koha 3.8 :
> * starts 2011-11
> * feature freeze 2012-03
> * release 2012-04
>
> In my proposal, Koha 4.0 has the following timeline :
> * defining the strategy & the roadmap start 2011-11 and end in 2012-01
> (3 months)
> * hacking starts in 2012-02
> * feature freeze start in 2012-09
> * release 2012-10
>
> It means there will/can have a real hacking overlap of something like 2
> months (feb-march 2012)
>
> According to me, we could even start immediately to list everything
> we're dreaming of.
> The 2nd step being to evaluate how we can achieve each goal, who can
> endorse the needed work, which priority for what.
>
> Maybe another point of disagreement/misunderstanding is that you propose
> "a 4.0 with everything we want" while I propose "a 4.0 with everything
> that can fit in the 6 months timeline"
> We switched from Feature-based release to Time-based release, and I
> definitely don't want to change this. This has been a  major good
> decision we shouldn't change !
>
> My second rule is "if you change something important in the structure of
> Koha, 1st digit get a +1". [ With the change of templating system, we
> could have updated the version to 4.0 instead of 3.6, that would not
> have been a scandal (frenchism suspected...) ! ]
>
> It means that, for example, we decide that the priorities are (from
> biggest to lowest)
> 1- update indexing engine
> 2- enable database persistency
> 3- arbitrary metadata formats (beyond MARC)
> Step 1 and 2 have volunteers & code & ... => it will be in 4.0
> Step 3 doesn't have a volunteer => it will be in 5.0
> After 4.0 there will be a 4.2 or  a 5.0 depending on step 3 being ready.
>
> I like the idea of a roadmap, with the following chapters :
> Will be in version XX :
>  * feature A already merged
>  * feature B already merged
>  * ...
> Should be in version XX :
>  * feature C, patch submitted, being examinated
>
> Could be in version XX :
>  * feature D, announced by mail at people.com
>
> Have been submitted but rejected for instance :
>  * feature E, patch does not apply
>  * feature F, failed QA
>  * ...
>
> (doesn't eclipse have such a roadmap ? not sure)
>
> Should I conclude that the version number should be decided/defined when
> feature freeze reached ? Maybe, i'm not sure.
>
> About your idea of 3.10, 3.12,... I fear/feel that we can't afford
> managing the conflicts that will result :
> * "4.0" has database persistency merged, we still lack "indexing engine
> changes", so 4.0 has not been released
> * a patch to enable "arbitrary biblio relationships" is submitted for
> 3.x It will be totally incompatible with "4.0 still unreleased" and we
> have a problem...
> > One of my other issues with the proposal was the "lightening" of
> > Quality Assurance standards for the first 3 months of the 3.8 release
> > cycle.
> You've forgotten to specify i've written "how exactly, To Be Discussed".
> This is only a main concern I have expressed before : smoothen things.
> The idea of sandboxes to have more ppl testing will be a step in this
> direction. I'll also send regular mails to try to motivate ppl to
> test/sign-off. Maybe that will be enough. But maybe we could also accept
> a derivative workflow like "there are some experienced ppl that can
> decide to do sign-off and passed QA at the same time, they're
> experienced&wise enough to decide if a patch is small/trivial enough to
> be applied without a 2nd eye checking". Or ther(s) rule(s) we could
> discuss (I have a lot of suggestions I could/will do). My idea is not to
> lower the quality.
>
> Ian, thanks to continue this thread.
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110912/5f935017/attachment.htm>