I have a trivial change for asynchat to shut up pychecker: /usr/local/lib/python2.2/asynchat.py:83: Local variable (why) not used /usr/local/lib/python2.2/asynchat.py:217: Local variable (why) not used (delete the "why" variable in both cases). Can I check in on the main trunk and have it go into 2.3 without disturbing the 2.2 release? I'm never sure during these alpha/beta/release candidate situations what is and isn't allowed (other than that Barry's new branch is clearly off-limits). This is such a trivial change that it seems like overkill to me to submit a bug report or a patch, have it assigned to someone who two weeks later says, "sure, looks fine to me - check it in". (Hint: For those of us with rotting neurons, whenever development enters a release phase such as we are in right now, it would be helpful to remind us what we can do as well as what we can't.) Skip
Yes, the release branch has been made. The trunk is all yours. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Skip Montanaro]
The things you can do are those you don't get publicly humiliated for doing. Sure, it's a two-pass algorithm, and even then it makes the set of things you can do at best recursively enumerable (there's no bound on how long it may take before you're attacked, so you can never know for sure that you're safe, only that if you're damned you'll *eventually* find out) -- but in the absence of a PEP, that's the best we can do for you <wink>. To a good first approximation, don't check in anything on the release *branch* without Barry's explicit advance blessing, and I expect you'll live to be appreciated in 2002.
"SM" == Skip Montanaro <skip@pobox.com> writes:
SM> Can I check in on the main trunk and have it go into 2.3 SM> without disturbing the 2.2 release? I'm never sure during SM> these alpha/beta/release candidate situations what is and SM> isn't allowed (other than that Barry's new branch is clearly SM> off-limits). Trunk checkins are always safe. We create a release branch specifically so that no strict freeze on checkins need be imposed on CVS committers. The release branch is always off-limits to everyone except those of us who are making the releases (or our designated bots), as per PEP 101. This way we can ensure a clean, controlled release branch but not hold up ongoing Python development and maintenance on the trunk. BTW, this policy is fairly new with Python 2.2 and, speaking as Release Manager, I think it has worked exceedingly well. We actually got the idea from the way Zope's CVS is managed, though we've tweaked the process a bit to suite Python's differing needs. aIMO, the most important adjustment was in finding the right balance between the need for a branch and the reality that the inevitable merge from branch back to trunk can be a royal PITA (ask Tim some time about is descr-branch merge experience. ;) Currently we try to branch at about noon (local time 'natch) the day before the release. This seems like a pretty good balance between the conflicting goals of release isolation and a pain-free trunk-merge. I know my announcement earlier today discouraged trunk checkins until we spin the Python 2.2 final release. I think that makes sense given that this is a "final" release, so there are a few special considerations. I'm willing to accept that my discouraging trunk checkins is just paranoia on my part ;). -Barry
Yes, the release branch has been made. The trunk is all yours. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Skip Montanaro]
The things you can do are those you don't get publicly humiliated for doing. Sure, it's a two-pass algorithm, and even then it makes the set of things you can do at best recursively enumerable (there's no bound on how long it may take before you're attacked, so you can never know for sure that you're safe, only that if you're damned you'll *eventually* find out) -- but in the absence of a PEP, that's the best we can do for you <wink>. To a good first approximation, don't check in anything on the release *branch* without Barry's explicit advance blessing, and I expect you'll live to be appreciated in 2002.
"SM" == Skip Montanaro <skip@pobox.com> writes:
SM> Can I check in on the main trunk and have it go into 2.3 SM> without disturbing the 2.2 release? I'm never sure during SM> these alpha/beta/release candidate situations what is and SM> isn't allowed (other than that Barry's new branch is clearly SM> off-limits). Trunk checkins are always safe. We create a release branch specifically so that no strict freeze on checkins need be imposed on CVS committers. The release branch is always off-limits to everyone except those of us who are making the releases (or our designated bots), as per PEP 101. This way we can ensure a clean, controlled release branch but not hold up ongoing Python development and maintenance on the trunk. BTW, this policy is fairly new with Python 2.2 and, speaking as Release Manager, I think it has worked exceedingly well. We actually got the idea from the way Zope's CVS is managed, though we've tweaked the process a bit to suite Python's differing needs. aIMO, the most important adjustment was in finding the right balance between the need for a branch and the reality that the inevitable merge from branch back to trunk can be a royal PITA (ask Tim some time about is descr-branch merge experience. ;) Currently we try to branch at about noon (local time 'natch) the day before the release. This seems like a pretty good balance between the conflicting goals of release isolation and a pain-free trunk-merge. I know my announcement earlier today discouraged trunk checkins until we spin the Python 2.2 final release. I think that makes sense given that this is a "final" release, so there are a few special considerations. I'm willing to accept that my discouraging trunk checkins is just paranoia on my part ;). -Barry
participants (4)
-
barry＠zope.com -
Guido van Rossum -
Skip Montanaro -
Tim Peters