In Florent's message on date screwup he mentioned 2.6.1...
I know 2.6.1 is supposed to be finished pretty soon but not within a week, right? :-)
Is there a plan, schedule etc for 2.6.1? I couldn't find it in the Wiki's but that doesn't mean much :) Want put ZCatalog Caching proposal (working on) and SQL Caching proposal in somewhere and Im not sure where to look. Cheers -- Andy McKay www.agmweb.ca
On Mon, 2002-10-21 at 13:33, Andy McKay wrote:
In Florent's message on date screwup he mentioned 2.6.1...
I know 2.6.1 is supposed to be finished pretty soon but not within a week, right? :-)
Is there a plan, schedule etc for 2.6.1? I couldn't find it in the Wiki's but that doesn't mean much :)
Want put ZCatalog Caching proposal (working on) and SQL Caching proposal in somewhere and Im not sure where to look.
And I want to put in an extession to TM to allow DAs to implement the 'vote' phase of TPC (very non intrusive, just another overridable method, previous DAs will keep working). Cheers, Leo. -- Ideas don't stay in some minds very long because they don't like solitary confinement.
Leonardo Rochael Almeida wrote:
On Mon, 2002-10-21 at 13:33, Andy McKay wrote:
In Florent's message on date screwup he mentioned 2.6.1...
I know 2.6.1 is supposed to be finished pretty soon but not within a week,
right? :-)
Is there a plan, schedule etc for 2.6.1? I couldn't find it in the Wiki's but that doesn't mean much :)
Want put ZCatalog Caching proposal (working on) and SQL Caching proposal in somewhere and Im not sure where to look.
And I want to put in an extession to TM to allow DAs to implement the 'vote' phase of TPC (very non intrusive, just another overridable method, previous DAs will keep working).
For sanity's sake, 2.6.x is now the current maintenance branch, not the place to put new features. New features should only go into 2.7. We need to get out of the hotfixes business. Adherence to strict rules is the right way to get there. Shane
For sanity's sake, 2.6.x is now the current maintenance branch, not the place to put new features. New features should only go into 2.7. We need to get out of the hotfixes business. Adherence to strict rules is the right way to get there.
And just for the record: The bad old Zope tradition of fixing bugs between the final beta and the actual release seems to be hard to kill. What would have been so difficult about calling the most recent release 2.6.0 b3? If it really is release-quality, it could become 2.6.0 final within a couple of days, but not BEFORE there was any beta phase ... Joachim
FWIW, the reason that there is a flurry of activity before any release is because people want to see features in a stable release version and by nature (IMHO) programmers are procrastinators. ;-) You could say that the folks in charge at ZC should back out any changes that happen in the period between final beta and final or that we should release another beta, but often ZC folks are the worst offenders due to customer requirements and a desire to be able to run customer software on a "stable release". Quis custodiet ipsos custodes? ;-) - C On Mon, 2002-10-21 at 14:14, Joachim Werner wrote:
For sanity's sake, 2.6.x is now the current maintenance branch, not the place to put new features. New features should only go into 2.7. We need to get out of the hotfixes business. Adherence to strict rules is the right way to get there.
And just for the record:
The bad old Zope tradition of fixing bugs between the final beta and the actual release seems to be hard to kill. What would have been so difficult about calling the most recent release 2.6.0 b3? If it really is release-quality, it could become 2.6.0 final within a couple of days, but not BEFORE there was any beta phase ...
Joachim
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Chris McDonough wrote:
FWIW, the reason that there is a flurry of activity before any release is because people want to see features in a stable release version and by nature (IMHO) programmers are procrastinators. ;-)
This doesn't fit with normal open source practice. Why are we starting to operate like this? cheers, Chris
On Tue, Oct 29, 2002 at 09:55:40AM +0000, Chris Withers wrote:
Chris McDonough wrote:
FWIW, the reason that there is a flurry of activity before any release is because people want to see features in a stable release version and by nature (IMHO) programmers are procrastinators. ;-)
This doesn't fit with normal open source practice. Why are we starting to operate like this?
It what world do you live, and can I move there? Every large open source project I've particpated in or kept track of has had this problem - it's _really hard_ to turn down cool new patches just because your supposed to be in feature freeze, trying to get a stable release out. What do _you_ think 'normal open source practice' is? Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Executive Director phone: 713-348-6166 Gulf Coast Consortium for Bioinformatics fax: 713-348-6182 Rice University MS-39 Houston, TX 77005
Ross J. Reedstrom wrote:
It what world do you live, and can I move there? Every large open source project I've particpated in or kept track of has had this problem - it's _really hard_ to turn down cool new patches just because your supposed to be in feature freeze, trying to get a stable release out.
What do _you_ think 'normal open source practice' is?
FWIW, see as an example http://developer.kde.org/development-versions/kde-3.0-release-plan.html and/or http://developer.kde.org/development-versions/kde-3.2-features.html Seems to work quite well for them. cheers, oliver
Oliver Bleutgen writes:
...
What do _you_ think 'normal open source practice' is?
FWIW, see as an example http://developer.kde.org/development-versions/kde-3.0-release-plan.html
and/or http://developer.kde.org/development-versions/kde-3.2-features.html
Seems to work quite well for them. Almost surely, I am unjust towards the KDE developers:
I identify the many k* programs with KDE. When I do this, then I have never seen that many bugs in the time before KDE. My X error log is full of KDE and k* program problems. Dieter
Ross J. Reedstrom wrote:
It what world do you live, and can I move there?
You miss the point ;-) The flurry to get features into a 'stable' release is what I was on about. If you flurry, the release won't be stable. I like the pattern of having stable releases and CVS or nightly builds for people who want the latest and greatest. That way everyone gets to contribute easily and freely and yet we still get truly stable versions. Maybe not to the extent of having seperate 'dev' and 'stable' streams a la Linux, but that's a good feeling in essence. Still, the overarching thing is release early and often. The fewer features in each release, the fewer problems of "I need this feature, but that means I also have to accept this one that I don't trust" cheers, Chris
On Wed, 30 Oct 2002, Chris Withers wrote:
The flurry to get features into a 'stable' release is what I was on about. If you flurry, the release won't be stable.
I like the pattern of having stable releases and CVS or nightly builds for people who want the latest and greatest. That way everyone gets to contribute easily and freely and yet we still get truly stable versions.
That's how FreeBSD tries to handle it (except that you do your own nightly builds if you want that). But every time, just before freature freeze time, there is a flurry of commits. Once feature freeze happens, however, there are only bug fixes. Likewise, with Zope my impression is that once the Beta is cut, we are in feature freeze. Now, ZC may not have operated that way in the past *entirely*, but I think we should from now on. A flurry of commits *before* feature freeze seems unaviodable, however. That's what deadlines are for, after all <grin>. --RDM
Likewise, with Zope my impression is that once the Beta is cut, we are in feature freeze. Now, ZC may not have operated that way in the past *entirely*, but I think we should from now on.
A flurry of commits *before* feature freeze seems unaviodable, however. That's what deadlines are for, after all <grin>.
--RDM
That has indeed been the case in my experience. Another aspect of this that might not be apparent if you are not the one who happens to be trying to manage the release process is that there is always a delicate balance between enforcing the letter of the law and making concessions to ensure that being a contributor is a rewarding experience rather than a frustrating one. Some things have to be taken on a case-by-case basis, and I can say with some authority that no matter what you choose, some people will praise you and some people will blast you for it :) Keep in mind, too, that the 2.6 release is really the first release that has had anywhere *near* this level of community contribution, so some rough edges should be expected. There is still plenty for all of us to learn. P.S. - I'm planning to do a little revamp of the dev homepage by the end of this week to simplify a few things and hopefully make it easier to know "what's going on", as well as posting the plans for 2.6.1 and much-misunderstood 2.7. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Wednesday, October 30, 2002, at 04:22 AM, Chris Withers wrote:
Ross J. Reedstrom wrote:
It what world do you live, and can I move there?
You miss the point ;-)
The flurry to get features into a 'stable' release is what I was on about. If you flurry, the release won't be stable.
I like the pattern of having stable releases and CVS or nightly builds for people who want the latest and greatest. That way everyone gets to contribute easily and freely and yet we still get truly stable versions.
Maybe not to the extent of having seperate 'dev' and 'stable' streams a la Linux, but that's a good feeling in essence.
Still, the overarching thing is release early and often. The fewer features in each release, the fewer problems of "I need this feature, but that means I also have to accept this one that I don't trust"
But release often is a BITCH for software configuration management. Good for developers, bad for deployers.
On Wed, 30 Oct 2002 13:32:59 -0700 Jeffrey P Shell <jeffrey@cuemedia.com> wrote:
On Wednesday, October 30, 2002, at 04:22 AM, Chris Withers wrote:
Ross J. Reedstrom wrote:
It what world do you live, and can I move there?
You miss the point ;-)
The flurry to get features into a 'stable' release is what I was on about. If you flurry, the release won't be stable.
I like the pattern of having stable releases and CVS or nightly builds for people who want the latest and greatest. That way everyone gets to contribute easily and freely and yet we still get truly stable versions.
Maybe not to the extent of having seperate 'dev' and 'stable' streams a la Linux, but that's a good feeling in essence.
Still, the overarching thing is release early and often. The fewer features in each release, the fewer problems of "I need this feature, but that means I also have to accept this one that I don't trust"
But release often is a BITCH for software configuration management. Good for developers, bad for deployers.
Hence the nightly build. Just for developers or early adopters. Not for deployers. -Casey
For sanity's sake, 2.6.x is now the current maintenance branch, not the place to put new features. New features should only go into 2.7. We need to get out of the hotfixes business. Adherence to strict rules is the right way to get there.
Thanks, you've answered my second question and I'll try to put these features intto 2.7. -- Andy McKay www.agmweb.ca
Hi all - can we get the http://collector.zope.org/Zope/432 fix into 2.6.1 *cough*andreas*cough*. This undoes a regression that currently requires all zwiki users to patch their zope source. -Simon
participants (14)
-
Andy McKay -
Brian Lloyd -
Casey Duncan -
Chris McDonough -
Chris Withers -
Dieter Maurer -
Jeffrey P Shell -
Joachim Werner -
Leonardo Rochael Almeida -
Oliver Bleutgen -
R. David Murray -
Ross J. Reedstrom -
Shane Hathaway -
Simon Michael