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 [email protected] 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 [email protected] 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/
