Commentary on Paul's Koha 3.8 Release Manager proposal

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Commentary on Paul's Koha 3.8 Release Manager proposal

Ian Walls
Everyone,


Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release Manager.  The details of his document can be found here: http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38

I thoroughly agree that the time has come to start thinking beyond the next stable release, and on to Koha 4.0.  Those of you who have seen either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know I'm very excited about the possibilities of where we can take Koha in it's next major iteration.  However, I disagree with a couple of the details of Paul's proposal.

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 would counter that, while we should continue releasing new features every 6 months on the 3.X line, Koha 4.0 should be defined by it's features.  Paul's proposal calls several features to be key, including Solr integration, database abstraction, updated online help, improved authentication stack and automated tests.  I agree that all these things are important and should be worked towards, but I'm not convinced they should be the sum total of the changes that define Koha 4.0

I would like to see the following in Koha 4.0:
  • arbitrary metadata formats (beyond MARC)
  • arbitrary biblio relationships
  • full support for authority records, including uploading through the GUI, automatic linking, "explode" searching and more
  • improvements to the borrower data structure (fewer pre-defined data fields, more flexibility)
  • separation of "receiving" and "payment" in acquisitions
  • serials import and export (MFHD, prediction patterns, etc)
  • many, many more things
I think that the community should meet and discuss what features are both desirable and reasonably likely to be completed in the next few years (is there interest by libraries to sponsor these developments, or from developers to code it "for fun"?).

Once a feature set is agreed on to "define" Koha 4.0, the developers of these features would meet to hash out what underlying structural changes would be required to make them happen.  Hopefully commonalities could be found, so that the underlying structure could be developed in a way that accommodates multiple developments at once.  Identifying these prerequisite changes early on would reduce the difficulties of rebasing developments, since we'd all be working off a similar set of base assumptions.  It would also provide a reasonable basis for excluding or delaying developments that don't fit into the overall plan.

Once the features were chosen and a framework for their development agreed upon, it would be time to code.  The development and submission process would be the same as it is now (basing patches off master and submitting to the patches listserv and Bugzilla).  As new features become ready, they would be incorporated into the time-based 3.X releases by the release manager for that particular cycle.  This way, what works is made available, and what needs more time continues to be tested until it's stable for production use.  Once all the agreed upon features were ready, it would be time to release Koha 4.0.  Hopefully, that would be with 1-2 years, but there would be flexibility here.

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.  If operating under the 1 year time frame for Koha 4.0 as outlined in Paul's proposal, this would seem necessary in order to get everything included in time.  Unfortunately, while the next 3 months would be dedicated to clean up of features rolled in, there is never any guarantee of bug fixes being generated in a timely fashion.  You cannot force people to write or sign off on bug fixes; we're all free agents here.  So code that has not been rigourously tested could get in and stay in for a long time, long after 4.0 would release, because no one knows how to test it or fix it.

However, if we operate under my proposed model, all code could continue to operate under the same quality assurance standards, and nothing that is broken or otherwise incomplete would make it in until it was ready.  Releases would still come out every 6 months, even if a major development was inoperable, until that development could be completed.

This has been a long email, so let me sum up.  I think:
  • we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month cycles using the current community practices for feature inclusion
  • we should, as a community, meet and decide what features we want to define Koha 4.0
  • the developers of those features should get together and come up with a unified plan for accomplishing them all, in a way that requires minimal rebasing
  • as new features become stable and tested, they should be folded into the 3.X line until all the features defined as "Koha 4.0" are ready
  • Once all the agreed upon features are complete, Koha 4.0 is then released.
I've already gotten some feedback on this in today's Koha IRC meeting, but I'd very much like to hear what the rest of the community thinks about this, particular in relation to Paul's proposal for 3.8 Release Manager.  Our time is limited for discussion, as the election time draws near, but hopefully I've made my thoughts clear enough for a dialogue to get started.  Please let me know if I've been at all unclear.

Cheers,


-Ian

--
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # <a href="tel:%28888%29%20900-8944" value="+18889008944" target="_blank">(888) 900-8944
http://bywatersolutions.com
[hidden email]
Twitter: @sekjal

_______________________________________________
Koha mailing list  http://koha-community.org
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: Commentary on Paul's Koha 3.8 Release Manager proposal

Henri-Damien LAURENT
Hi Ian,
Great Idea.
But I fear that what you propose would then lead to having Koha 4.0 be a
new Perl 6, i.e. it will never come out (emmm.. no, Perl 6 will be
released... some day). You will never be able to provide users with a
schedule. And if all the new features are to be integrated step by step
in the process. When 4.0 will be released, all its features will already
be in 3.xxx.
If ppl are to work on plumbings,  rebasing the work and making its
integration smooth needs to be quick unless you have to manage a de
facto fork which leads to more overhead, less effective work.

>     * arbitrary metadata formats (beyond MARC)
>     * arbitrary biblio relationships
>     * full support for authority records, including uploading through
>       the GUI, automatic linking, "explode" searching and more
>     * improvements to the borrower data structure (fewer pre-defined
>       data fields, more flexibility)
>     * separation of "receiving" and "payment" in acquisitions
>     * serials import and export (MFHD, prediction patterns, etc)
>     * many, many more things

Are those things asked by users ? I think you are mixing developers and
user features. When looking at the General meetings, very few USERS are
coming. Why ? From a french point of view, the language frontier is
really hard and the way to work is really different from the american
way. Making KUDOS meet Kohala and have tight contacts should be a
priority in order to make a list of features. I think our system should
be user centric. But we should also entice users to sit at a table and
get a list of feature in a schedule. Otherwise, you will just have
wishfull thinking, and make idle promises. (It was not to come to that
that I came into Free Softwares.)

You could have added federated search, Full text search in documents and
so on.


My 2 cents.
--
Henri-Damien LAURENT

Le 07/09/2011 23:58, Ian Walls a écrit :

> Everyone,
>
>
> Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release
> Manager.  The details of his document can be found here:
> http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38
>
> I thoroughly agree that the time has come to start thinking beyond the
> next stable release, and on to Koha 4.0.  Those of you who have seen
> either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know
> I'm very excited about the possibilities of where we can take Koha in
> it's next major iteration.  However, I disagree with a couple of the
> details of Paul's proposal.
>
> 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 would counter that, while we should continue releasing new features
> every 6 months on the 3.X line, Koha 4.0 should be defined by it's
> features.  Paul's proposal calls several features to be key, including
> Solr integration, database abstraction, updated online help, improved
> authentication stack and automated tests.  I agree that all these things
> are important and should be worked towards, but I'm not convinced they
> should be the sum total of the changes that define Koha 4.0
>
> I would like to see the following in Koha 4.0:
>
>     * arbitrary metadata formats (beyond MARC)
>     * arbitrary biblio relationships
>     * full support for authority records, including uploading through
>       the GUI, automatic linking, "explode" searching and more
>     * improvements to the borrower data structure (fewer pre-defined
>       data fields, more flexibility)
>     * separation of "receiving" and "payment" in acquisitions
>     * serials import and export (MFHD, prediction patterns, etc)
>     * many, many more things
>
> I think that the community should meet and discuss what features are
> both desirable and reasonably likely to be completed in the next few
> years (is there interest by libraries to sponsor these developments, or
> from developers to code it "for fun"?).
>
> Once a feature set is agreed on to "define" Koha 4.0, the developers of
> these features would meet to hash out what underlying structural changes
> would be required to make them happen.  Hopefully commonalities could be
> found, so that the underlying structure could be developed in a way that
> accommodates multiple developments at once.  Identifying these
> prerequisite changes early on would reduce the difficulties of rebasing
> developments, since we'd all be working off a similar set of base
> assumptions.  It would also provide a reasonable basis for excluding or
> delaying developments that don't fit into the overall plan.
>
> Once the features were chosen and a framework for their development
> agreed upon, it would be time to code.  The development and submission
> process would be the same as it is now (basing patches off master and
> submitting to the patches listserv and Bugzilla).  As new features
> become ready, they would be incorporated into the time-based 3.X
> releases by the release manager for that particular cycle.  This way,
> what works is made available, and what needs more time continues to be
> tested until it's stable for production use.  Once all the agreed upon
> features were ready, it would be time to release Koha 4.0.  Hopefully,
> that would be with 1-2 years, but there would be flexibility here.
>
> 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.  If
> operating under the 1 year time frame for Koha 4.0 as outlined in Paul's
> proposal, this would seem necessary in order to get everything included
> in time.  Unfortunately, while the next 3 months would be dedicated to
> clean up of features rolled in, there is never any guarantee of bug
> fixes being generated in a timely fashion.  You cannot force people to
> write or sign off on bug fixes; we're all free agents here.  So code
> that has not been rigourously tested could get in and stay in for a long
> time, long after 4.0 would release, because no one knows how to test it
> or fix it.
>
> However, if we operate under my proposed model, all code could continue
> to operate under the same quality assurance standards, and nothing that
> is broken or otherwise incomplete would make it in until it was ready.
> Releases would still come out every 6 months, even if a major
> development was inoperable, until that development could be completed.
>
> This has been a long email, so let me sum up.  I think:
>
>     * we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month
>       cycles using the current community practices for feature inclusion
>     * we should, as a community, meet and decide what features we want
>       to define Koha 4.0
>     * the developers of those features should get together and come up
>       with a unified plan for accomplishing them all, in a way that
>       requires minimal rebasing
>     * as new features become stable and tested, they should be folded
>       into the 3.X line until all the features defined as "Koha 4.0" are
>       ready
>     * Once all the agreed upon features are complete, Koha 4.0 is then
>       released.
>
> I've already gotten some feedback on this in today's Koha IRC meeting,
> but I'd very much like to hear what the rest of the community thinks
> about this, particular in relation to Paul's proposal for 3.8 Release
> Manager.  Our time is limited for discussion, as the election time draws
> near, but hopefully I've made my thoughts clear enough for a dialogue to
> get started.  Please let me know if I've been at all unclear.
>
> Cheers,
>
>
> -Ian
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944 <tel:%28888%29%20900-8944>
> http://bywatersolutions.com
> [hidden email] <mailto:[hidden email]>
> Twitter: @sekjal
>
>
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> [hidden email]
> http://lists.katipo.co.nz/mailman/listinfo/koha

_______________________________________________
Koha mailing list  http://koha-community.org
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

FW: Commentary on Paul's Koha 3.8 Release Manager proposal

Marcel de Rooy
In reply to this post by Ian Walls
I think both proposals (from Paul and Ian) contain very good points, are ambitious and motivating for the community. With people like Ian and Paul in the release team, we will definitely reach a Koha 4.0!

I would however not favor working in parallel on Koha 3.8 and 4.0 as well as maintaining 3.6.X (and possible even 3.4.X for a while). I think that three or four versions together with lowering quality standards will not result in a better product, but could imply more bugs, rebasing problems and time lost on synchronizing between versions, testing in multiple versions, etc.
Why not keep it simpler? Develop in master (heading to 4.0 and solR), and keep 3.6.X stable (as soon as 3.6.X is there, declare 3.4.X end-of-life too). Just focus on those two versions.

A long feature list for 4.0 is very nice and Ian's development plan may theoretically be the best way to go, but probably hard to realize in practice. A simpler approach would be: as soon as solR and searching is ready and stable, we reach 4.0. This could be after 3.8, 3.10, .. (Stick to the 6m cycle.)

We have been growing into a higher QA standard when we came from 3.2. I think it would be a pity if we already lower that standard too quickly. A problem is obviously the longer time between submission and pushing. Probably, we could improve in that area by adding some persons at the QA level (Ian may have two assistants in 3.8?), asking the bug wranglers to test older patches first and let them communicate more about these patches, and doing QA first on these older signed patches. Currently, time does not really rule selection of a patch in signoff or QA, but other factors like author, size, attractive title, etc.  
At the same time we could allow people perhaps to sign the more easy, trivial patches themselves (especially if they have them running in production already somewhere). If QA would disagree, they could lower the patch status back to Needs signoff for getting another external test. We could make a proposal how to change current procedures for this without compromizing quality.
What we should avoid, is large, very large patches without test plan. These patches did not come through now too. Which is quite understandable. Such patches should be broken up into manageable units with a test plan.

Hope this helps,

Marcel

> Everyone,
>
>
> Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release
> Manager.  The details of his document can be found here:
> http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38
>
> I thoroughly agree that the time has come to start thinking beyond the
> next stable release, and on to Koha 4.0.  Those of you who have seen
> either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know
> I'm very excited about the possibilities of where we can take Koha in
> it's next major iteration.  However, I disagree with a couple of the
> details of Paul's proposal.
>
> 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 would counter that, while we should continue releasing new features
> every 6 months on the 3.X line, Koha 4.0 should be defined by it's
> features.  Paul's proposal calls several features to be key, including
> Solr integration, database abstraction, updated online help, improved
> authentication stack and automated tests.  I agree that all these things
> are important and should be worked towards, but I'm not convinced they
> should be the sum total of the changes that define Koha 4.0
>
> I would like to see the following in Koha 4.0:
>
>     * arbitrary metadata formats (beyond MARC)
>     * arbitrary biblio relationships
>     * full support for authority records, including uploading through
>       the GUI, automatic linking, "explode" searching and more
>     * improvements to the borrower data structure (fewer pre-defined
>       data fields, more flexibility)
>     * separation of "receiving" and "payment" in acquisitions
>     * serials import and export (MFHD, prediction patterns, etc)
>     * many, many more things
>
> I think that the community should meet and discuss what features are
> both desirable and reasonably likely to be completed in the next few
> years (is there interest by libraries to sponsor these developments, or
> from developers to code it "for fun"?).
>
> Once a feature set is agreed on to "define" Koha 4.0, the developers of
> these features would meet to hash out what underlying structural changes
> would be required to make them happen.  Hopefully commonalities could be
> found, so that the underlying structure could be developed in a way that
> accommodates multiple developments at once.  Identifying these
> prerequisite changes early on would reduce the difficulties of rebasing
> developments, since we'd all be working off a similar set of base
> assumptions.  It would also provide a reasonable basis for excluding or
> delaying developments that don't fit into the overall plan.
>
> Once the features were chosen and a framework for their development
> agreed upon, it would be time to code.  The development and submission
> process would be the same as it is now (basing patches off master and
> submitting to the patches listserv and Bugzilla).  As new features
> become ready, they would be incorporated into the time-based 3.X
> releases by the release manager for that particular cycle.  This way,
> what works is made available, and what needs more time continues to be
> tested until it's stable for production use.  Once all the agreed upon
> features were ready, it would be time to release Koha 4.0.  Hopefully,
> that would be with 1-2 years, but there would be flexibility here.
>
> 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.  If
> operating under the 1 year time frame for Koha 4.0 as outlined in Paul's
> proposal, this would seem necessary in order to get everything included
> in time.  Unfortunately, while the next 3 months would be dedicated to
> clean up of features rolled in, there is never any guarantee of bug
> fixes being generated in a timely fashion.  You cannot force people to
> write or sign off on bug fixes; we're all free agents here.  So code
> that has not been rigourously tested could get in and stay in for a long
> time, long after 4.0 would release, because no one knows how to test it
> or fix it.
>
> However, if we operate under my proposed model, all code could continue
> to operate under the same quality assurance standards, and nothing that
> is broken or otherwise incomplete would make it in until it was ready.
> Releases would still come out every 6 months, even if a major
> development was inoperable, until that development could be completed.
>
> This has been a long email, so let me sum up.  I think:
>
>     * we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month
>       cycles using the current community practices for feature inclusion
>     * we should, as a community, meet and decide what features we want
>       to define Koha 4.0
>     * the developers of those features should get together and come up
>       with a unified plan for accomplishing them all, in a way that
>       requires minimal rebasing
>     * as new features become stable and tested, they should be folded
>       into the 3.X line until all the features defined as "Koha 4.0" are
>       ready
>     * Once all the agreed upon features are complete, Koha 4.0 is then
>       released.
>
> I've already gotten some feedback on this in today's Koha IRC meeting,
> but I'd very much like to hear what the rest of the community thinks
> about this, particular in relation to Paul's proposal for 3.8 Release
> Manager.  Our time is limited for discussion, as the election time draws
> near, but hopefully I've made my thoughts clear enough for a dialogue to
> get started.  Please let me know if I've been at all unclear.
>
> Cheers,
>
>
> -Ian
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944 <tel:%28888%29%20900-8944>
> http://bywatersolutions.com
> [hidden email] <mailto:[hidden email]>
> Twitter: @sekjal
>
>
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> [hidden email]
> http://lists.katipo.co.nz/mailman/listinfo/koha

_______________________________________________
Koha mailing list  http://koha-community.org
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list  http://koha-community.org
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

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

MJ Ray-2
In reply to this post by Ian Walls
Ian Walls <[hidden email]> [...]
> 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. [...]

A minor disagreement is with the platform.  Paul's proposal seems to
be for 3.8 and 4.0 RM, yet there's very little detail on 4.0 because
the community discussion hasn't really started: lots of great features
suggested, some scary changes, but not much agreed.  Let's agree the
RM for 3.8 and then when the next release rolls around, then let's see
what we want to do then?

In general, I'm fine with folding into 3.x progressively.  Seems
like a good idea.  (Now find me more libraries so I can spend
more time on it... ;-) )

Regards,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/
_______________________________________________
Koha mailing list  http://koha-community.org
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha