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

[Paul Poulain]

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