Dear committers,
if the buffer/array-related blockers are resolved in time, the rc1 will be released one week from now.
Since some people asked: at the moment we are not in the RC phase yet, so fixing bugs is allowed, but it would be advisable to have a second committer review any nontrivial fix.
From the release of rc1, I will keep the code that will become 3.3 in a separate repo, so that commits to "default" on cpython *won't* go into 3.3. You will have to notify me of all commits that you think *should* go there, so that I can cherry-pick them. Not all bugfixes fall into that category; only showstopper-level ones. The rest will have to wait for 3.3.1.
cheers, Georg
Why not creating a 3.3.0 branch to prepare the release instead of a different repository?
Victor Le 19 août 2012 13:05, "Georg Brandl" <g.brandl@gmx.net> a écrit :
Dear committers,
if the buffer/array-related blockers are resolved in time, the rc1 will be released one week from now.
Since some people asked: at the moment we are not in the RC phase yet, so fixing bugs is allowed, but it would be advisable to have a second committer review any nontrivial fix.
From the release of rc1, I will keep the code that will become 3.3 in a separate repo, so that commits to "default" on cpython *won't* go into 3.3. You will have to notify me of all commits that you think *should* go there, so that I can cherry-pick them. Not all bugfixes fall into that category; only showstopper-level ones. The rest will have to wait for 3.3.1.
cheers, Georg
______________________________**_________________ python-committers mailing list python-committers@python.org http://mail.python.org/**mailman/listinfo/python-**committers<http://mail.python.org/mailman/listinfo/python-committers>
Well, I can certainly push the branch back to the main repo, but I really don't want anyone else committing to it.
Georg
On 21.08.2012 00:05, Victor Stinner wrote:
Why not creating a 3.3.0 branch to prepare the release instead of a different repository?
Victor
Le 19 août 2012 13:05, "Georg Brandl" <g.brandl@gmx.net <mailto:g.brandl@gmx.net>> a écrit :
Dear committers, if the buffer/array-related blockers are resolved in time, the rc1 will be released one week from now. Since some people asked: at the moment we are not in the RC phase yet, so fixing bugs is allowed, but it would be advisable to have a second committer review any nontrivial fix. >From the release of rc1, I will keep the code that will become 3.3 in a separate repo, so that commits to "default" on cpython *won't* go into 3.3. You will have to notify me of all commits that you think *should* go there, so that I can cherry-pick them. Not all bugfixes fall into that category; only showstopper-level ones. The rest will have to wait for 3.3.1. cheers, Georg _________________________________________________ python-committers mailing list python-committers@python.org <mailto:python-committers@python.org> http://mail.python.org/__mailman/listinfo/python-__committers <http://mail.python.org/mailman/listinfo/python-committers>
Georg Brandl wrote:
From the release of rc1, I will keep the code that will become 3.3 in a separate repo, so that commits to "default" on cpython *won't* go into 3.3. You will have to notify me of all commits that you think *should* go there, so that I can cherry-pick them. Not all bugfixes fall into that category; only showstopper-level ones. The rest will have to wait for 3.3.1.
If commits to default go to 3.3.1 after RC 1, when will the 3.3/3.4 separation happen?
Petri
Zitat von Petri Lehtinen <petri@digip.org>:
Georg Brandl wrote:
From the release of rc1, I will keep the code that will become 3.3 in a separate repo, so that commits to "default" on cpython *won't* go into 3.3. You will have to notify me of all commits that you think *should* go there, so that I can cherry-pick them. Not all bugfixes fall into that category; only showstopper-level ones. The rest will have to wait for 3.3.1.
If commits to default go to 3.3.1 after RC 1, when will the 3.3/3.4 separation happen?
As soon as Georg creates the maintenance branch :-)
PEP 101 says that this happens immediately after creating the 3.3.0 tag, before pushing that to the release clone. After the release announcement is sent, the release clone gets merged back to the main repo.
People interested in that should really read PEP 101. I think it's a master-piece of detail (going back to Barry Warsaw's passion for detail and documentation).
Regards, Martin
participants (4)
-
Georg Brandl -
martin＠v.loewis.de -
Petri Lehtinen -
Victor Stinner