Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 8, 2008, at 12:35 AM, raymond.hettinger wrote:
Author: raymond.hettinger Date: Thu May 8 06:35:20 2008 New Revision: 62848
Log: Frozensets do not benefit from autoconversion.
Since the trunk buildbots appear to be mostly happy (well those that are connected anyway), and because I couldn't get the releases out last night, I'll let this one slide. I'd like to find a way to more forcefully enforce commit freezes for the betas though. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCLk2nEjvBPtnXfVAQJxiwP/VPTmeKVLoKkc/xIF0tc/lb6pT7kZ0swL b1M2TUkl/+xOuKf3J2EIkHOiKdNNmivl80nG/wP9/VTa7lVJGnWgIeLi0yC20Q9n wvtHaXCrHDc4/ibiShjwYqD4YR0BGwJI7BrlyCYzohbjFK6QYsxd+5a96Cipb/cB +K/Akjqry4Q= =xQfb -----END PGP SIGNATURE-----
On Thu, May 8, 2008 at 6:32 AM, Barry Warsaw <barry@python.org> wrote:
Since the trunk buildbots appear to be mostly happy (well those that are connected anyway), and because I couldn't get the releases out last night, I'll let this one slide. I'd like to find a way to more forcefully enforce commit freezes for the betas though.
I wonder if you couldn't alter the server side commit hook to reject everything with the message "Sorry, we're in a freeze." (You'd have to make an exception for yourself.) -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 8, 2008, at 7:54 AM, Benjamin Peterson wrote:
On Thu, May 8, 2008 at 6:32 AM, Barry Warsaw <barry@python.org> wrote:
Since the trunk buildbots appear to be mostly happy (well those that are connected anyway), and because I couldn't get the releases out last night, I'll let this one slide. I'd like to find a way to more forcefully enforce commit freezes for the betas though.
I wonder if you couldn't alter the server side commit hook to reject everything with the message "Sorry, we're in a freeze." (You'd have to make an exception for yourself.)
This is exactly what I'm thinking about! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCLrNnEjvBPtnXfVAQITDwP/WGqlRHSfvE668clPM3gshhYbAapZcF+e mNKGwu407/q03LYRqHr2QY0gBxsySJBWl5OsozmJUOTc7NEY/E/MtiauauzCJiyO 24sJ2V52aROwYBLG+4tLFcaGmWmnsWPg79Qj/yJQKMMiH5OznPfagLECOjlwDZZA ianWqOZxeYc= =xyD7 -----END PGP SIGNATURE-----
Barry Warsaw schrieb:
This is exactly what I'm thinking about!
-1 A technical solution never solves a social problem. It's just going to cause more social and technical problems. All community members with svn write privileges must subscribe to the Python developer list. Committers must check the lists prior to a check in if a release is immanent. Releases are announced at least four days prior to svn freeze so it's not going to be a problem. The problem often lies with occasional committers and maintainers of stdlib packages. People need to show more discipline or eventually we have to (temporarily) revoke their privileges. Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 8, 2008, at 8:21 AM, Christian Heimes wrote:
Barry Warsaw schrieb:
This is exactly what I'm thinking about!
-1
A technical solution never solves a social problem. It's just going to cause more social and technical problems.
In this case I disagree. Given our global nature and the vast amounts of email we all get, I think a friendly little svn commit hook reminder is a simple and workable solution. This commit lock really doesn't need to be in place for very long. Optimistically, I only need it long enough to create the tags, which /normally/ should take me 10 minutes.
All community members with svn write privileges must subscribe to the Python developer list. Committers must check the lists prior to a check in if a release is immanent. Releases are announced at least four days prior to svn freeze so it's not going to be a problem. The problem often lies with occasional committers and maintainers of stdlib packages. People need to show more discipline or eventually we have to (temporarily) revoke their privileges.
Or aggressively back out any changes from freeze time to tag time. If we don't add the commit hook lock, I will be very strict about this come the betas. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCL+KnEjvBPtnXfVAQIkxgQAqXXwZjHyI93L1xEvrIPYGkTugxlgEva/ bj9ip59XqB6EYS8NnciJU29WZhcc3WnEoOsdWk7qwYV0qOc2YOgYh775GF4Q2S/A 5qVw+oePFIGCWMhezVG/JYph8V6T0QL36hhgd78WqBJKa2C7IpKEjh3HATwY8DQL nouyqdmIDJo= =Vohh -----END PGP SIGNATURE-----
On Thu, May 8, 2008 at 8:20 AM, Barry Warsaw <barry@python.org> wrote:
Or aggressively back out any changes from freeze time to tag time. If we don't add the commit hook lock, I will be very strict about this come the betas.
I know this way is fairly entrenched in the python release process, but it sounds like it's using the tools incorrectly. In particular with subversion is very easy (compared to cvs) to branch and to switch branches locally. Why not create a new prerelease branch at the beginning of freeze and only merge in the critical changes? This way only the release manager need know or care about the branch, and nobody else has to really modify his behavior. Then tag, move, and/or delete the branch as desired. The obvious stumbling blocks include buildbots not following the new branch (this could be a blocker), and release scripts possibly needing modifications if they contain direct svn url references. -- Michael Urman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 8, 2008, at 9:41 AM, Michael Urman wrote:
On Thu, May 8, 2008 at 8:20 AM, Barry Warsaw <barry@python.org> wrote:
Or aggressively back out any changes from freeze time to tag time. If we don't add the commit hook lock, I will be very strict about this come the betas.
I know this way is fairly entrenched in the python release process, but it sounds like it's using the tools incorrectly. In particular with subversion is very easy (compared to cvs) to branch and to switch branches locally. Why not create a new prerelease branch at the beginning of freeze and only merge in the critical changes? This way only the release manager need know or care about the branch, and nobody else has to really modify his behavior. Then tag, move, and/or delete the branch as desired.
The obvious stumbling blocks include buildbots not following the new branch (this could be a blocker), and release scripts possibly needing modifications if they contain direct svn url references.
I definitely think we'd want the buildbots to track the release branches, and it's a bit of a pain to get the release scripts to deal with the svn switches. Right now I think the freeze window is pretty short (barring unforeseen networking snafus) that it's not worth it. However, once the release process is smooth enough, maybe this little freeze hiccup will be worth eliminating. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCMNEHEjvBPtnXfVAQIDogP+NVpyE7AhUS1Eerqv/N+ERTuKnmy/rSNQ wQhOlAxlvx/lPgm0Mi70C9cA60ogxwGE+nJPf0RQxN2bVfhE/+fvElRl9x7xuoo3 wAK6/zzItqMCP4bpaT8sbsqn4tPB4OCKr0eM/SgZMxrHZkHHZwLTVAw81h40Fmr3 A30V6JpZpdU= =q3uu -----END PGP SIGNATURE-----
Michael Urman writes:
I know this way is fairly entrenched in the python release process, but it sounds like it's using the tools incorrectly. In particular with subversion is very easy (compared to cvs) to branch and to switch branches locally. Why not create a new prerelease branch at the beginning of freeze and only merge in the critical changes?
Well, speaking from experience: - some of the "critical changes" may only get committed on the release branch - something different from what's in the mainline may get committed on the release branch - the milestones are on a sideline, not on the mainline. Getting these points right is essential to ensure that the beta testers' work is actually relevant to the development process, that bisection searches work correctly, etc.
only the release manager need know or care about the branch, and nobody else has to really modify his behavior.
Behavior modification is the main point of having a release cycle. Setting deadlines, changing the nature of the patches, bringing issues to closure, etc. A release without a freeze is like a sentence without a period, IMO.
Christian Heimes wrote:
Barry Warsaw schrieb:
This is exactly what I'm thinking about!
-1
A technical solution never solves a social problem. It's just going to cause more social and technical problems.
All community members with svn write privileges must subscribe to the Python developer list. Committers must check the lists prior to a check in if a release is immanent. Releases are announced at least four days prior to svn freeze so it's not going to be a problem. The problem often lies with occasional committers and maintainers of stdlib packages. People need to show more discipline or eventually we have to (temporarily) revoke their privileges.
It's actually the time zone issues that get me in relation to code freezes... so I just try to avoid committing anything for a day or two :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Thu, May 08, 2008 at 11:23:11PM +1000, Nick Coghlan wrote:
It's actually the time zone issues that get me in relation to code freezes... so I just try to avoid committing anything for a day or two :)
Subscribers to the python-dev digests may also not see a posting immediately, waiting until the next digest is sent. --amk
On Thu, May 08, 2008, A.M. Kuchling wrote:
On Thu, May 08, 2008 at 11:23:11PM +1000, Nick Coghlan wrote:
It's actually the time zone issues that get me in relation to code freezes... so I just try to avoid committing anything for a day or two :)
Subscribers to the python-dev digests may also not see a posting immediately, waiting until the next digest is sent.
Heck, I'm not on the digest and I still have been seeing posts after a week (though that's the fault of a balky mailserver that should be fixed). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Help a hearing-impaired person: http://rule6.info/hearing.html
amk> Subscribers to the python-dev digests may also not see a posting amk> immediately, waiting until the next digest is sent. Or python-dev subscribers might delete the announcement of the freeze without paying close attention to it then wonder a few hours later whether or not it's okay to check anything in. (Speaking as someone with a problem in this area.) I'm all in favor of a technical fix to my memory problems. <0.5 wink> Skip
On Thu, 8 May 2008 10:21:54 pm Christian Heimes wrote:
Barry Warsaw schrieb:
This is exactly what I'm thinking about!
-1
A technical solution never solves a social problem. It's just going to cause more social and technical problems.
That's certainly not true. The social problem of people throwing their "night soil" out into the streets had a technical solution, namely sewerage systems. Or if you prefer a more computer-related example, the social problem of having people on a shared computer have access to files you don't want them to have access to is solved by the technical solution of file permissions and ACLs. I have no opinion on this specific problem, but it is equally fallacious to say that social problems_never_ have technical solutions as it is to say that they _always_ have technical solutions. -- Steven D'Aprano
On 2008-05-08 13:59, Barry Warsaw wrote:
On May 8, 2008, at 7:54 AM, Benjamin Peterson wrote:
On Thu, May 8, 2008 at 6:32 AM, Barry Warsaw <barry@python.org> wrote:
Since the trunk buildbots appear to be mostly happy (well those that are connected anyway), and because I couldn't get the releases out last night, I'll let this one slide. I'd like to find a way to more forcefully enforce commit freezes for the betas though.
I wonder if you couldn't alter the server side commit hook to reject everything with the message "Sorry, we're in a freeze." (You'd have to make an exception for yourself.)
This is exactly what I'm thinking about!
+1, that's easy to do with Subversion and doesn't hurt anyone. Please also use a term like "freeze" or "frozen" in the subject line of the announcement - perhaps even in capital letters. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 09 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
In the past I seem to recall that the Python code proper might be frozen (for a day or two) before a release, but that it was okay to still commit changes to non-code files such as documentation or files in Misc. Is this still the case in the new release-early-release-often regime? Is the intention to make the duration of the code freeze so short (a few minutes or hours) that it's not worth the effort to make this distinction? Skip
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 9, 2008, at 8:15 AM, skip@pobox.com wrote:
In the past I seem to recall that the Python code proper might be frozen (for a day or two) before a release, but that it was okay to still commit changes to non-code files such as documentation or files in Misc. Is this still the case in the new release-early-release-often regime? Is the intention to make the duration of the code freeze so short (a few minutes or hours) that it's not worth the effort to make this distinction?
For the alphas, that's certainly been the case because it hasn't been necessary to coordinate all the Experts. IOW, it's okay for the Windows installer to get uploaded a few hours after the tarballs. For the betas, rcs and finals, I think we want a little bit more coordination (correct me if you disagree). So in that case, there may be a longer freeze. Even in that case, I don't envision more than a 24 hour freeze hopefully. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCRR5HEjvBPtnXfVAQLa+gP8CL9koa5eGBvP8g+CA8l61SIuluHNbPkq SH7uOiPMeuIX392xy82ixnXjYTlCJn9epWouYkiWta3GA+ZaCcmTFFavZ3ZbLbE3 uxfzhCWsZ5EUW5/iDCOUrlEwuxXJ6FU4naRTaTCBTELXRKvb3sI5C2pFjrb6JTZc hP2hP6m+A2Y= =avCD -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 9, 2008, at 6:44 AM, M.-A. Lemburg wrote:
On 2008-05-08 13:59, Barry Warsaw wrote:
On May 8, 2008, at 7:54 AM, Benjamin Peterson wrote:
On Thu, May 8, 2008 at 6:32 AM, Barry Warsaw <barry@python.org> wrote:
Since the trunk buildbots appear to be mostly happy (well those that are connected anyway), and because I couldn't get the releases out last night, I'll let this one slide. I'd like to find a way to more forcefully enforce commit freezes for the betas though. I wonder if you couldn't alter the server side commit hook to reject everything with the message "Sorry, we're in a freeze." (You'd have to make an exception for yourself.) This is exactly what I'm thinking about!
+1, that's easy to do with Subversion and doesn't hurt anyone.
Agreed. Look for it for the first beta. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCRQvXEjvBPtnXfVAQKyLwP8D0AVX+jgvy04hM207eeWRZb3JcHMtZuP ZcOuBQsCsVFppCxAreYIwfa0e6TD2LHBV4uz/G7Nxt6qNI6SY7lHQezNg4RezFwJ e93HAGdD0djj4BrL/xCr0wrK6wCwjodcvcjFdqTjEdLnkS7KGM9ooW8ZdYjQp6jI E+ZLDdhQ/KY= =24yM -----END PGP SIGNATURE-----
participants (11)
-
A.M. Kuchling -
Aahz -
Barry Warsaw -
Benjamin Peterson -
Christian Heimes -
M.-A. Lemburg -
Michael Urman -
Nick Coghlan -
skip＠pobox.com -
Stephen J. Turnbull -
Steven D'Aprano