TRUNK UNFROZEN (release is done)
The first beta is out, so the trunk is unfrozen, and available for checkins. Now that we're in beta, we shouldn't see any new features or behaviour changing fixes going into the trunk, unless it's been seen and agreed to on python-dev. I currently plan for a second beta in either 2 or 3 weeks, and then, assuming all goes well, a release candidate a couple of weeks after that. Anthony (apologies in the pause in getting the release email out - an unexpectedly hectic weekend popped up without notice)
Anthony Baxter wrote:
The first beta is out, so the trunk is unfrozen, and available for checkins.
Now that we're in beta, we shouldn't see any new features or behaviour changing fixes going into the trunk, unless it's been seen and agreed to on python-dev.
Why not create a release branch? That would free up the trunk for new work and reduce the chance of new features creeping in. I realize this is discussed briefly in PEP 101, but that PEP doesn't give a rational for waiting until the final release to make a release branch. It makes more sense to me to make the branch when features are frozen, which means the beta. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Why not create a release branch? That would free up the trunk for new work and reduce the chance of new features creeping in.
I prefer the current approach. New features can wait a bit. Anyone working on new stuff should Probably be focused on bug reports right now. We're not that far away from having Py2.4 done anyway. Adding a branch would make it a tiny bit more difficult to fix bugs. This is doubly true for non-developers who want to submit patches. Also, branching creates extra work because at some point the bug fixes and new features would need to be merged. Raymond
Jim Fulton <jim@zope.com> writes:
Anthony Baxter wrote:
The first beta is out, so the trunk is unfrozen, and available for checkins. Now that we're in beta, we shouldn't see any new features or behaviour changing fixes going into the trunk, unless it's been seen and agreed to on python-dev.
Why not create a release branch? That would free up the trunk for new work and reduce the chance of new features creeping in.
I realize this is discussed briefly in PEP 101, but that PEP doesn't give a rational for waiting until the final release to make a release branch. It makes more sense to me to make the branch when features are frozen, which means the beta.
Didn't this get tried before? Are you volunteering to port all the various bugfixy type things from whichever branch they get committed on to the other? I'm sure as hell not. Cheers, mwh -- We did requirements and task analysis, iterative design, and user testing. You'd almost think programming languages were an interface between people and computers. -- Steven Pemberton (one of the designers of Python's direct ancestor ABC)
Michael Hudson wrote:
Jim Fulton <jim@zope.com> writes:
Anthony Baxter wrote:
The first beta is out, so the trunk is unfrozen, and available for checkins. Now that we're in beta, we shouldn't see any new features or behaviour changing fixes going into the trunk, unless it's been seen and agreed to on python-dev.
Why not create a release branch? That would free up the trunk for new work and reduce the chance of new features creeping in.
I realize this is discussed briefly in PEP 101, but that PEP doesn't give a rational for waiting until the final release to make a release branch. It makes more sense to me to make the branch when features are frozen, which means the beta.
Didn't this get tried before?
I dunno. This is what we do for Zope, and I think it works well.
Are you volunteering to port all the various bugfixy type things from whichever branch they get committed on to the other?
I'm not talking about any new branches. I'm just suggesting that the branch should be made when features are frozen, rather than waiting until the final release. BTW, if we switched to subversion, porting fixes accross branches would become a lot easier. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Why not create a release branch? That would free up the trunk for new work and reduce the chance of new features creeping in.
What specific features are you thinking of that you want to creep into HEAD before 2.4 is released? (without including them in 2.4, of course). The release may happen before December, after all. Regards, Martin
Martin v. Löwis wrote:
Jim Fulton wrote:
Why not create a release branch? That would free up the trunk for new work and reduce the chance of new features creeping in.
What specific features are you thinking of that you want to creep into HEAD before 2.4 is released? (without including them in 2.4, of course). The release may happen before December, after all.
No features. I just think it makes more sense to create the release branch when you make the first beta. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
No features. I just think it makes more sense to create the release branch when you make the first beta.
That is common in other projects. It does have the problem that you have to apply bug-fixes twice, which is tedious to do. Not branching only hurts if there are significant sub-projects that need to share up-to-date sources, which is not the case for Python. We don't even branch for the final release, which I consider a (minor) flaw. Instead, the maintenance branch is created *after* the release. Regards, Martin
On Tue, 2004-10-26 at 13:41, "Martin v. Löwis" wrote:
That is common in other projects. It does have the problem that you have to apply bug-fixes twice, which is tedious to do. Not branching only hurts if there are significant sub-projects that need to share up-to-date sources, which is not the case for Python.
We don't even branch for the final release, which I consider a (minor) flaw. Instead, the maintenance branch is created *after* the release.
/me is pining for subversion on sourceforge ;) -Barry
Martin v. Löwis wrote:
Jim Fulton wrote:
No features. I just think it makes more sense to create the release branch when you make the first beta.
That is common in other projects. It does have the problem that you have to apply bug-fixes twice,
That only makes a difference for a short time. Eventually there will be a maintenance branch.
which is tedious to do.
It is *much* less so with subversion. We should switch. :)
Not branching only hurts if there are significant sub-projects that need to share up-to-date sources, which is not the case for Python.
I think that branching would tend to enforce the feature freeze. I don't feel strongly about this. I was just a little surprised. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
That only makes a difference for a short time. Eventually there will be a maintenance branch.
Yes. However, between a beta an the final release, there are likely many bug fixes in a short period of time, whereas (hopefully) the frequency of bug fixes goes down after a release.
which is tedious to do.
It is *much* less so with subversion. We should switch. :)
Both Barry and you make this claim, which makes me curious. How precisely is it more easy to apply the same change to two branches in subversion? Being a long time subversion user, I'ld normally just use the same procedure I use in CVS, i.e. just apply the patch twice, and commit it twice.
I think that branching would tend to enforce the feature freeze.
Hmm. I'm both uncertain whether that would indeed be the case, and whether it would be a good thing. You seem the be saying that there would be less changes on the branch. That might be the case. In projects that do use this approach, it often means that the burden on the release manager is increased, who now has to make sure that bugs get not only fixed in the trunk, but also on the branch. I don't think I want that. Regards, Martin
Martin v. Löwis wrote:
Jim Fulton wrote:
...
which is tedious to do.
It is *much* less so with subversion. We should switch. :)
Both Barry and you make this claim, which makes me curious. How precisely is it more easy to apply the same change to two branches in subversion? Being a long time subversion user, I'ld normally just use the same procedure I use in CVS, i.e. just apply the patch twice, and commit it twice.
With CVS either: - When creating the branch, I have to be very carreful about tags, so that I can tell CVS to apply differences made between the 2 tags, or - I have to apply changes to each individual file affected. With subversion, every revision is is effectively a tag. Merging is usually just a matter of merging differences between 2 repository revision numbers. This makes a huge difference when multiple files are involved.
I think that branching would tend to enforce the feature freeze.
Hmm. I'm both uncertain whether that would indeed be the case,
I find that having a separate branch makes it absolutely unambiguous that only bug fixes should be created there. <shrug>
and whether it would be a good thing. You seem the be saying that there would be less changes on the branch. That might be the case.
I'm saying that there would be fewer feature changes made. This definately seems like a good thing if features are supposed to be frozen. Python hasn't always done a good job of avoiding feature changes during beta cycles or on maintenence branches. If avoiding changes in such situations is desireable, as I think it is, then extra process to discourage such changes would be good. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
With subversion, every revision is is effectively a tag. Merging is usually just a matter of merging differences between 2 repository revision numbers. This makes a huge difference when multiple files are involved.
Ah, that. I don't worry about this difference too much. When I apply a change, it usually comes from SF, where it usually is in the form of a patch. So applying the patch to both the HEAD and a maintenance branch is: cd py2.4 cvs up patch -p0 < /tmp/name_of_patch (make, test, etc) cvs commit cd ../py2.3 cvs up patch -p0 < /tmp/name_of_patch (make, test, etc) cvs commit To my understanding, you are saying it is very much the same for svn. The only difference is that back-porting of patches afterwards is easier for svn - that may be true, but is irrelevant for applying SF patches.
I find that having a separate branch makes it absolutely unambiguous that only bug fixes should be created there. <shrug>
I don't think it makes it so for all developers. Between branching the beta, and the final release, it might be still reasonable to add features (in a strict sense) - the same is actually true after the release. Whether a branch is created or not would be immaterial to me.
Python hasn't always done a good job of avoiding feature changes during beta cycles or on maintenence branches. If avoiding changes in such situations is desireable, as I think it is, then extra process to discourage such changes would be good.
There is an ongoing debate within both the Python developers, and the Python users, whether strict rejection of new features is a good thing. I've personally come to the conclusion that I will bow to whatever decision the release manager decides. Regards, Martin
Martin v. Löwis wrote:
Jim Fulton wrote:
With subversion, every revision is is effectively a tag. Merging is usually just a matter of merging differences between 2 repository revision numbers. This makes a huge difference when multiple files are involved.
Ah, that. I don't worry about this difference too much. When I apply a change, it usually comes from SF, where it usually is in the form of a patch.
...
The only difference is that back-porting of patches afterwards is easier for svn - that may be true, but is irrelevant for applying SF patches.
Well, I never backport SF patches. :)
I find that having a separate branch makes it absolutely unambiguous that only bug fixes should be created there. <shrug>
I don't think it makes it so for all developers. Between branching the beta, and the final release, it might be still reasonable to add features (in a strict sense) - the same is actually true after the release. Whether a branch is created or not would be immaterial to me.
Then we disagree strongly about what should happen. I don't see any point in a feature freeze if you are going to then change features. ;) IMO, it is really bad to make feature changes after a beta release or in bug-fix releases. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Tue, 2004-10-26 at 18:44, Jim Fulton wrote:
IMO, it is really bad to make feature changes after a beta release or in bug-fix releases.
Don't worry, we won't need overly elaborate processes <wink> to keep this under control. Anthony's enough of a hard-ass to strongly discourage new features by public humiliation and intimidation. that's-why-we-love-him-or-better-him-than-me-ly y'rs, -Barry
Barry Warsaw wrote:
Don't worry, we won't need overly elaborate processes <wink> to keep this under control. Anthony's enough of a hard-ass to strongly discourage new features by public humiliation and intimidation.
I prefer to think of it as a campaign of education and mockery, in relevant proportions. As far as the original point (branching at the beta point, rather than post-final-release) - I've seen little demand for making this happen, and it increases both the workload and (much more importantly) the chance for a visit from Mr Cockup. But it's something we could do now if there's a real groundswell of people who want to get stuff into the trunk for 2.5 that extra month early <wink>. I'm also planning for more frequent releases during the beta cycle, so if all things go perfectly, I anticipate something like: beta2: Wednesday, November 3rd RC1: Wednesday, November 18th final: Tuesday, November 30th Obviously this is also dependent on Martin and Fred's time, nd any other feedback people have to offer. I think this is a realistic schedule... Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Wed, Oct 27, 2004 at 11:07:04AM +1000, Anthony Baxter wrote:
beta2: Wednesday, November 3rd RC1: Wednesday, November 18th final: Tuesday, November 30th
Any room in there for a bug day? Or do you think it wouldn't be advisable? Bug day = lots of changes, so maybe we don't want that to happen at the beta stage. The best weekends for a bug day might be Nov. 6 or 13th (between beta2 and RC1), or this coming weekend (before beta2). I still won't have time to run it, so someone will have to jump in. --amk
A.M. Kuchling wrote:
Any room in there for a bug day? Or do you think it wouldn't be advisable? Bug day = lots of changes, so maybe we don't want that to happen at the beta stage.
I'm not sure. If there was one, I'd hope it could be tightly focussed on only bugs relevant to the release - this would probably require someone to keep an eye on the bugday channel to make sure that this is handled appropriately. I don't have time to do this, unfortunately. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
A.M. Kuchling wrote:
The best weekends for a bug day might be Nov. 6 or 13th (between beta2 and RC1), or this coming weekend (before beta2). I still won't have time to run it, so someone will have to jump in. I suspect many of us in the USA may be doing some election work, so the 6th or 13th would be a lot better.
-- -- Scott David Daniels Scott.Daniels@Acm.Org
On Tue, Oct 26, 2004 at 09:41:35PM -0400, A.M. Kuchling wrote:
The best weekends for a bug day might be Nov. 6 or 13th (between beta2 and RC1), or this coming weekend (before beta2). I still won't have time to run it, so someone will have to jump in.
I finally decided to stop postponing doing this. I'll be running a bug day on November 7. I'll be in our office with some coworkers: any Dutch Pythoneers are welcome to join us for some 'real life' Python hacking! Cheers, Johannes
On Tuesday 26 October 2004 09:07 pm, Anthony Baxter wrote:
As far as the original point (branching at the beta point, rather than post-final-release) - I've seen little demand for making this happen, and it increases both the workload and (much more importantly) the chance for a visit from Mr Cockup. But it's
Indeed it does. We don't need that.
something we could do now if there's a real groundswell of people who want to get stuff into the trunk for 2.5 that extra month early <wink>.
As someone who works daily using the Zope 3 Way, I don't think it makes much sense for Python. No matter how easy Subversion makes moving patches around, it is another opportunity for a screwup. I don't see any reason to make the branch earlier than the first release candidate. We don't have a history of accidental inclusion of new features; when we've added things, it was done intentionally. (I'm not endorsing a policy on *that* here, just noting that we don't have a problem caused by the lack of an early branch.)
beta2: Wednesday, November 3rd RC1: Wednesday, November 18th final: Tuesday, November 30th
This looks good for me at this point. -Fred -- Fred L. Drake, Jr. <fred at zope.com> Zope Corporation
Barry Warsaw wrote:
On Tue, 2004-10-26 at 18:44, Jim Fulton wrote:
IMO, it is really bad to make feature changes after a beta release or in bug-fix releases.
Don't worry, we won't need overly elaborate processes <wink> to keep this under control. Anthony's enough of a hard-ass to strongly discourage new features by public humiliation and intimidation.
I dunno. It doesn't seem as though there is much agreement on this. If we can't agree on the goal, it seems hard for Anthony to enforce or encourage it. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (10)
-
"Martin v. Löwis" -
A.M. Kuchling -
Anthony Baxter -
Barry Warsaw -
Fred Drake -
Jim Fulton -
Johannes Gijsbers -
Michael Hudson -
Raymond Hettinger -
Scott David Daniels