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

Jim Fulton 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)

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

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

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

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

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

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 It's never too late to have a happy childhood.

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 It's never too late to have a happy childhood.

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

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