Re: [Koha] Proposal to form Koha Technical Committee (and Time Based Releases)
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. *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
On 21 Nov 2010 10:04, "Lori Bowen Ayre" <lori.ayre@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. *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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
* Lori Bowen Ayre (lori.ayre@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@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
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@catalyst.net.nz>wrote:
* Lori Bowen Ayre (lori.ayre@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@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-----
Reply inline: On Sat, November 20, 2010 21:33, Chris Cormack wrote:
* Lori Bowen Ayre (lori.ayre@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.
Chris Cormack's reading of David Lang's message as explaining some uncooperative behaviour may be a possible reading but I have some doubt that it was the intended meaning. At least in this context, I think that David should be given the benefit of the doubt unless David would explain otherwise.
Lets just try a time based release and see how it works for us, like the community decided.
Chris
[...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
On 22 November 2010 20:11, Thomas Dukleth <kohalist@agogme.com> wrote:
Reply inline:
On Sat, November 20, 2010 21:33, Chris Cormack wrote:
* Lori Bowen Ayre (lori.ayre@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.
Chris Cormack's reading of David Lang's message as explaining some uncooperative behaviour may be a possible reading but I have some doubt that it was the intended meaning. At least in this context, I think that David should be given the benefit of the doubt unless David would explain otherwise.
Thomas, I was replying to Lori, not David, which is why I quoted the things she said, not David. To clarify I had no issue with what David said. Chris
participants (4)
-
Chris Cormack -
Chris Cormack -
Lori Bowen Ayre -
Thomas Dukleth