[Koha] Proposal to form Koha Technical Committee (and Time Based Releases)

[Lori Bowen Ayre]

Chris,

I was in fact thinking of BibLibre.  I consider your company, BibLibre and
Liblime as three "companies" that have contributed the largest percentage of
the code.  Maybe I'm wrong.

And I am aware that the current plan is to continue with time-based releases
(during your tenure and beyond).  I have no doubt that Paul will continue
that policy because it is critical to his success as a software developer
with clients wit expectations that their deliverables will be met in a
timely fashion.

I was trying to emphasize the importance of time based releases especially
for our commercial contributors which in turn benefits all of us.

Lori

On Sat, Nov 20, 2010 at 1:33 PM, Chris Cormack <chrisc at catalyst.net.nz>wrote:

> * Lori Bowen Ayre (lori.ayre at galecia.com) wrote:
> >    I want to pull out these paragraphs from David Lang's email because I
> >    think it is an important point about the benefits of sticking to
> >    time-based releases.  I think if we had stuck to this principle, we
> >    wouldn't be having the troubles we are having (as a community) with
> some
> >    of our biggest contributors needing to support versions of Koha that
> are
> >    different from the latest official version.
>
> Wow.
>
> The single biggest contributor to Koha over time, in terms of a simple
> lines of code metric, Biblibre, suggested we try a time based release
> for 3.4. The community agreed.
>
> Biblibre have, and I have faith always
> will, contribute all their code upstream. In fact they spent a serious
> amount of time after the hackfest working with others to get their
> patches in a state that they could go through QA.
>
> I am not sure who these other big
> contributors that you speak of are? Galen, Joe Atzberger, Chris
> Nighswonger, Owen Leonard, MJ, me?.
>
> I actually find it quite reprehensible to suggest that the forks
> are the fault of previous release managers. Everyone with eyes and ears
> knows the real reason.
>
> Lets just try a time based release and see how it works for us, like the
> community decided.
>
> Chris
>
> >
> >      Several years of time based releases after many years of 'let the
> dates
> >      slip, the release will be better' seems to show pretty decisivly
> that
> >      frequent releases with what's ready at that time work better in
> practice
> >      than delaying a release until the features that were tagged for it
> are
> >      all ready.
> >
> >      if you delay a release until the feature is ready, there is a lot
> >      of preasure to declare it ready when it really isn't, because people
> >      really want all the other features that are in a new release.
> >
> >      because the releases aren't predictable, developers really want thir
> >      stuff to go into _this_ release because they don't know how long
> they
> >      will have to wait for the next one. If you have frequent releases,
> the
> >      knowledge of when the next release will happen (and therefor when
> the
> >      code will be upstream)
> >
> >    Well said, David.  And here here!  And ++
> >    Lori Ayre
>
> > _______________________________________________
> > Koha mailing list  http://koha-community.org
> > Koha at lists.katipo.co.nz
> > http://lists.katipo.co.nz/mailman/listinfo/koha
>
>
> --
> Chris Cormack
> Catalyst IT Ltd.
> +64 4 803 2238
> PO Box 11-053, Manners St, Wellington 6142, New Zealand
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkzoPq8ACgkQZgbcHEvgMLMCSQCfSfUELZNdrvYDDQgM9sirLYs3
> NVsAn1JtZkFTsstw3lfBx/VXDpreLTyR
> =xTGK
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20101120/e0174981/attachment.htm