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:
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@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@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@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@bywatersolutions.com
Twitter: @sekjal