Chris,<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>I was trying to emphasize the importance of time based releases especially for our commercial contributors which in turn benefits all of us.</div><div><br></div><div>Lori</div><div><br><div class="gmail_quote">
On Sat, Nov 20, 2010 at 1:33 PM, Chris Cormack <span dir="ltr"><<a href="mailto:chrisc@catalyst.net.nz">chrisc@catalyst.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">* Lori Bowen Ayre (<a href="mailto:lori.ayre@galecia.com">lori.ayre@galecia.com</a>) wrote:<br>
</div><div class="im">> I want to pull out these paragraphs from David Lang's email because I<br>
> think it is an important point about the benefits of sticking to<br>
> time-based releases. I think if we had stuck to this principle, we<br>
> wouldn't be having the troubles we are having (as a community) with some<br>
> of our biggest contributors needing to support versions of Koha that are<br>
> different from the latest official version.<br>
<br>
</div>Wow.<br>
<br>
The single biggest contributor to Koha over time, in terms of a simple<br>
lines of code metric, Biblibre, suggested we try a time based release<br>
for 3.4. The community agreed.<br>
<br>
Biblibre have, and I have faith always<br>
will, contribute all their code upstream. In fact they spent a serious<br>
amount of time after the hackfest working with others to get their<br>
patches in a state that they could go through QA.<br>
<br>
I am not sure who these other big<br>
contributors that you speak of are? Galen, Joe Atzberger, Chris<br>
Nighswonger, Owen Leonard, MJ, me?.<br>
<br>
I actually find it quite reprehensible to suggest that the forks<br>
are the fault of previous release managers. Everyone with eyes and ears<br>
knows the real reason.<br>
<br>
Lets just try a time based release and see how it works for us, like the<br>
community decided.<br>
<br>
Chris<br>
<div class="im"><br>
><br>
> Several years of time based releases after many years of 'let the dates<br>
> slip, the release will be better' seems to show pretty decisivly that<br>
> frequent releases with what's ready at that time work better in practice<br>
> than delaying a release until the features that were tagged for it are<br>
> all ready.<br>
><br>
> if you delay a release until the feature is ready, there is a lot<br>
> of preasure to declare it ready when it really isn't, because people<br>
> really want all the other features that are in a new release.<br>
><br>
> because the releases aren't predictable, developers really want thir<br>
> stuff to go into _this_ release because they don't know how long they<br>
> will have to wait for the next one. If you have frequent releases, the<br>
> knowledge of when the next release will happen (and therefor when the<br>
> code will be upstream)<br>
><br>
> Well said, David. And here here! And ++<br>
> Lori Ayre<br>
<br>
</div><div><div></div><div class="h5">> _______________________________________________<br>
> Koha mailing list <a href="http://koha-community.org" target="_blank">http://koha-community.org</a><br>
> <a href="mailto:Koha@lists.katipo.co.nz">Koha@lists.katipo.co.nz</a><br>
> <a href="http://lists.katipo.co.nz/mailman/listinfo/koha" target="_blank">http://lists.katipo.co.nz/mailman/listinfo/koha</a><br>
<br>
<br>
</div></div><font color="#888888">--<br>
Chris Cormack<br>
Catalyst IT Ltd.<br>
+64 4 803 2238<br>
PO Box 11-053, Manners St, Wellington 6142, New Zealand<br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAkzoPq8ACgkQZgbcHEvgMLMCSQCfSfUELZNdrvYDDQgM9sirLYs3<br>
NVsAn1JtZkFTsstw3lfBx/VXDpreLTyR<br>
=xTGK<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br></div>