Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson schrieb: Howdy, I'm going through the motions of getting my newly added build slave in a half decent state. I think the buildbot should have a name different from 'x86 XP'. (Martin, Neal?) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code freeze?
Barry Warsaw wrote: Alterntaively, I guess you could just suggest that people check the buildbot page for their platforms before downloading Yes, good idea. I'm only going to cut source tarballs for the alphas. I apologize for having doubt in your plan, and I can certainly appreciate the work you will be doing as release manager. But.. I don't understand who these alpha releases are supposed to be for, and who they will serve. When I first saw this plan, I thought ok, you're the man.. But now I wonder even more if they are only going to be source tarballs. Who is the intended audience of these alphas? It seems like cutting only source tarballs is targeting developers, and if that is the case, I wonder if you have misplaced your motivations. I'm not sure what developer outside of the core community would want to work with something missing key features and released fairly arbitrarily. Ok, I grant you that it's a monthly cycle, but there are no feature milestones involved, so it's fairly arbitrary from a utility standpoint; it's not clear to me that we are even worrying about all of the buildbots being green before releasing. More to the point, I don't know why a developer wouldn't just checkout from SVN in any case. Certainly if they are going to help root out bugs, then we would like them to be using the trunk if possible. I fear that once an alpha is 2 weeks old, we will start saying please check if its still a problem on the trunk. A mild concern is how this effects checkins with individuals either trying to meet a deadline or even wait until after an alpha release to checkin a large change. I'm not sure this will happen, but having releases scheduled without feature milestones attached certainly changes the environment for work to be done in. I guess I am hoping to understand better how these alphas serve us. Again, I apologize if that sounded judgmental, but I wanted to make sure that releasing alphas was the best plan. And again, I appreciate your enthusiasm and effort. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson schrieb: Howdy, I'm going through the motions of getting my newly added build slave in a half decent state. The external.bat and external-amd64.bat files needed the following in order to build db-4.4.20: Index: external.bat === --- external.bat(revision 61125) +++ external.bat(working copy) @@ -10,7 +10,8 @@ @rem Sleepycat db if not exist db-4.4.20 svn export http://svn.python.org/projects/external/db-4.4.20 if not exist db-4.4.20\build_win32\debug\libdb44sd.lib ( - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static ) @rem OpenSSL This change is fine by me (if it works ;-). Do you have commit rights, or do you want me to check it in? (This is against trunk, same thing would apply to py3k I guess, given that we're using %VS90COMNTOOLS%vsvars32.bat there too.) I guess it will be merged automatically by Christian. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Thomas Heller wrote: I guess it will be merged automatically by Christian. I won't have time today. Sorry Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
I'm going through the motions of getting my newly added build slave in a half decent state. I think the buildbot should have a name different from 'x86 XP'. (Martin, Neal?) Thomas Yeah, I've dropped Martin a note regarding this. The community bots refer to Windows Server 2003 boxes as just that, so perhaps a rename to 'x86 Windows Server 2008' is appropriate. FWIW as it's a 64-bit box, I'm hoping to get a slave set up for 'x64 Windows Server 2008' as well. (As far as I can see, the x64/x86 nature of the slave is dictated by the master, correct? i.e. I can't tweak/clone this myself?) Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code freeze?
Scott Dial schrieb: Barry Warsaw wrote: Alterntaively, I guess you could just suggest that people check the buildbot page for their platforms before downloading Yes, good idea. I'm only going to cut source tarballs for the alphas. I apologize for having doubt in your plan, and I can certainly appreciate the work you will be doing as release manager. But.. I don't understand who these alpha releases are supposed to be for, and who they will serve. When I first saw this plan, I thought ok, you're the man.. But now I wonder even more if they are only going to be source tarballs. Who is the intended audience of these alphas? It seems like cutting only source tarballs is targeting developers, and if that is the case, I wonder if you have misplaced your motivations. I'm not sure what developer outside of the core community would want to work with something missing key features and released fairly arbitrarily. Ok, I grant you that it's a monthly cycle, but there are no feature milestones involved, so it's fairly arbitrary from a utility standpoint; it's not clear to me that we are even worrying about all of the buildbots being green before releasing. More to the point, I don't know why a developer wouldn't just checkout from SVN in any case. Certainly if they are going to help root out bugs, then we would like them to be using the trunk if possible. I fear that once an alpha is 2 weeks old, we will start saying please check if its still a problem on the trunk. For one thing, releases generate news, meaning that people will be made aware that things are moving, that Python is well underway to its next major versions, and maybe will be more inclined to look at what's new, or check out a release. For some people, the label alpha X is more acceptable than SVN version, even for projects whose SVN trunk is generally quite stable as is the case with Python. Even if that's the only thing accomplished by the alpha releases, they do not do any harm. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson wrote: - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static The upgrade is requires only once. It probably belongs next to the checkout or svn up and not in the build section. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Code freeze?
Christian Heimes wrote: Barry Warsaw wrote: Okay, let's go ahead and make it official. I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to that: 2200 UTC Friday 29-Feb-2008. Linux is looking good. I've fixed some minor Windows issue in the last 30 minutes. I found one strange behavior. Some tests were failing because iter(fileobj) where fileobj is a tempfile._TemporaryFileWrapper failed. Apparently iter() doesn't use __getattr__ to acquire the __iter__ method. Is this behavior deliberately? The interpreter is actually permitted to bypass the instance when looking up magic methods. Whether it does or not is implementation dependent - even CPython varies its behaviour depending on the specific circumstance (e.g. the translation of with statements to bytecode ends up using normal GET_ATTR opcodes, so those will see __enter__ and __exit__ methods on instances, but most of the magic method lookups from C code bypass the instance and go straight to the relevant tp_* slot). I'd call this behaviour a bug in _TemporaryFileWrapper, since it's delegation trick in __getattr__ isn't guaranteed to work for the magic methods. I'm actually becoming less and less enamoured of that shortcut every day - given that we've already had to spell out the file method and property delegation for SpooledTemporaryFile in 2.6, I'm tempted to start spelling it out for _TemporaryFileWrapper as well. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code freeze?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 29, 2008, at 5:21 AM, Georg Brandl wrote: Scott Dial schrieb: Barry Warsaw wrote: Alterntaively, I guess you could just suggest that people check the buildbot page for their platforms before downloading Yes, good idea. I'm only going to cut source tarballs for the alphas. I apologize for having doubt in your plan, and I can certainly appreciate the work you will be doing as release manager. But.. I don't understand who these alpha releases are supposed to be for, and who they will serve. For one thing, releases generate news, meaning that people will be made aware that things are moving, that Python is well underway to its next major versions, and maybe will be more inclined to look at what's new, or check out a release. I completely agree. There's another very important aspect of doing alpha releases, and that is to debug the /process/ of releasing. I need to see how far we've come in the years since I RM'd last. How smoothly we can coordinate all the various players? What does it take to update the website? Where are the glitches in the process that slows everything down or blocks certain steps? What is the state of the tools, and is there anything else we can automate? I also want to see if sticking to the monthly cycle can make us all work more productively as a community, so that we know when bugs need to be fixed in order to show up in the next release, and so on. Think of it this way: the alphas are for /us/ as much as for our users. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8fz7XEjvBPtnXfVAQI0zgQAnp8nva5qxIoN4ocr7uNXeNxJ+BdP2lMA 8GN1kv3R/+9ny6h/iakfyE0lt1hvHP+uchchd4zo1CWQ390h1W8eR0SpzbubRYFP Bvdnup7K1zSSGe0ILGoa6Zv8VCYI4vET0PsxM+bkhj8NblwQQu1xUcc6CnYBtapM c9TwZum/ODg= =A2cs -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code freeze?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 29, 2008, at 7:39 AM, Nick Coghlan wrote: Barry Warsaw wrote: Think of it this way: the alphas are for /us/ as much as for our users. In that vein, I think the monthly alphas may also help as a means for setting personal deadlines for things we're working on. Implement for 2.6 is a bit of a wishy-washy deadline at some vague point in the future - it doesn't provide much impetus to sit down and spend an afternoon or evening getting it done. Implement for next 2.6 alpha, which will be cut in 3 weeks, 2 days and 16 hours is a real concrete target that can be aimed for (even if I'm the only person that knows I'm aiming for it for a given bug fix or feature). It should also motivate at least a monthly review of the buildbot status, and is already motivating a push towards making the buildbots a more reliable indicator of the health of the source tree. Sure, they may mostly be internal milestones (with third parties waiting for a feature-complete alpha or the first beta), but I think there is a decent chance the approach will turn out to be beneficial. That's my hope too! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8gBKnEjvBPtnXfVAQK5egP+JgrZd68JtkyhLOGhcd0aBjhQEJM4e2FO HcRION8EeI4jhg5KQWOt/KmP6CBLblGq50RFI0afsLaJVapk4U6MFTB0LQus3LgX myd0zK5egu+sblFfKFfe5mMKn5T1Mx5HCLuOE4g3uwuFtdddsGMvYwCyqjm3smq1 T38bbujy234= =xSv1 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Christian Heimes: Trent Nelson wrote: - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static The upgrade is requires only once. It probably belongs next to the checkout or svn up and not in the build section. Makes sense. So we're looking at something like: @rem Sleepycat db if not exist db-4.4.20 ( svn export http://svn.python.org/projects/external/db-4.4.20 devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln ) if not exist db-4.4.20\build_win32\debug\libdb44sd.lib ( devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug ) I'll test this when I get to work and report back. Trent. -- http://www.onresolve.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson schrieb: Christian Heimes: Trent Nelson wrote: - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static The upgrade is requires only once. It probably belongs next to the checkout or svn up and not in the build section. Makes sense. So we're looking at something like: @rem Sleepycat db if not exist db-4.4.20 ( svn export http://svn.python.org/projects/external/db-4.4.20 devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln ) if not exist db-4.4.20\build_win32\debug\libdb44sd.lib ( devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug ) I'll test this when I get to work and report back. Great. What's the difference between these two? vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Thomas Heller wrote: What's the difference between these two? vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug Devenv is the name of the VS GUI executable but it can *also* be used as a CLI to build stuff. devenv doesn't work for Express Edition. vcbuild seems to be the preferred CLI app to build a project but it's limited. I think it doesn't support /upgrade. MvL probably has a better answer ;) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code freeze?
Nick Coghlan wrote: In composing this response, I also realised why the new tempfile tests worked for me before I checked them in: I was testing it on the trunk, where _TemporaryFileWrapper is a classic class. Special method lookup on classic classes doesn't include the 'direct-to-type' optimisation, so those tests work with the tempfile module as written on 2.x. tempfile is also using different implementation for TemporaryFile on Win32. On Windows it's an alias for NamedTemporaryFile while on Unix it's using a file descriptor of an unlinked file. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Christian Heimes: Thomas Heller wrote: What's the difference between these two? vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug Devenv is the name of the VS GUI executable but it can *also* be used as a CLI to build stuff. devenv doesn't work for Express Edition. vcbuild seems to be the preferred CLI app to build a project but it's limited. I think it doesn't support /upgrade. Hummm. My answer would be more along the lines of devenv works, vcbuild doesn't ;-) S:\buildbots\python\trunk.nelson-windows\db-4.4.20\build_win32vcbuild Berkeley_DB.sln /build Debug /project db_static Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022 Copyright (C) Microsoft Corporation. All rights reserved. vcbuild.exe : warning VCBLD6002: invalid option /build specified. The option was ignored. vcbuild.exe : warning VCBLD6002: invalid option /project specified. The option was ignored. vcbuild.exe : warning VCBLD6002: invalid option db_static specified. The option was ignored. vcbuild.exe : error VCBLD0006: invalid configuration name: DEBUG. Compare this to: S:\buildbots\python\trunk.nelson-windows\db-4.4.20\build_win32devenv Berkeley_DB.sln /build Debug /project db_static Microsoft (R) Visual Studio Version 9.0.21022.8. Copyright (C) Microsoft Corp. All rights reserved. == Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped == I don't know how the existing vcbuild line ever worked, given the following output from vcbuild /?: Usage: vcbuild [options] [project|solution] [config|$ALL] Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Code freeze?
Christian Heimes wrote: Is this documented somewhere? The docs say See the :meth:`__getattribute__` method below for a way to actually get total control over attribute access.. I just checked, and the restriction is now documented in the development docs in the section on special methods at [1]. It was backported from the Py3k docs and isn't part of the docs for 2.5 or earlier versions. The gist is that special methods *must* be defined directly on a new-style class in order for the interpreter to reliably access them, but defining them on a new-style instance *may* still affect the interpreter's behaviour in some cases (but won't necessarily do so). In composing this response, I also realised why the new tempfile tests worked for me before I checked them in: I was testing it on the trunk, where _TemporaryFileWrapper is a classic class. Special method lookup on classic classes doesn't include the 'direct-to-type' optimisation, so those tests work with the tempfile module as written on 2.x. Unfortunately, proxies like _TemporaryFileWrapper that rely on __getattr__ to provide special methods simply won't work properly when implemented as new-style classes - for that, they need to spell out the overridden special methods the way SpooledTemporaryFile does. I think we may need a -3 warning that detects situations where __*__ attributes are retrieved via a __getattr__ implementation on a classic class - classes being used that way have a very high chance of breaking when ported to 3.0 and I can't see any possible way for 2to3 to detect them. Cheers, Nick. [1] http://docs.python.org/dev/reference/datamodel.html#special-method-names -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson wrote: S:\buildbots\python\trunk.nelson-windows\db-4.4.20\build_win32devenv Berkeley_DB.sln /build Debug /project db_static Microsoft (R) Visual Studio Version 9.0.21022.8. Copyright (C) Microsoft Corp. All rights reserved. == Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped == I don't know how the existing vcbuild line ever worked, given the following output from vcbuild /?: Usage: vcbuild [options] [project|solution] [config|$ALL] Try: vcbuild /useenv db_static.vcproj Debug|Win32 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (02/22/08 - 02/29/08) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1711 open (+34) / 12326 closed (+13) / 14037 total (+47) Open issues with patches: 457 Average duration of open issues: 741 days. Median duration of open issues: 1110 days. Open Issues Breakdown open 1690 (+34) pending21 ( +0) Issues Created Or Reopened (50) ___ sqlite numeric type conversion problems 02/27/08 http://bugs.python.org/issue2157reopened ghaering patch dl broken on non-ILP32 platforms 02/22/08 CLOSED http://bugs.python.org/issue2164created notting Fix for test_logging 02/23/08 CLOSED http://bugs.python.org/issue2165created therve pydistutils.cfg won't be found on Windows02/23/08 http://bugs.python.org/issue2166created tarek Remove unused imports02/23/08 CLOSED http://bugs.python.org/issue2167created calvin patch gdbm needs to be iterable02/23/08 CLOSED http://bugs.python.org/issue2168created therve patch Adding DOCTYPE and html, body tags to SimpleHTTPServer 02/23/08 CLOSED http://bugs.python.org/issue2169created ajaksu2 rewrite of minidom.Node.normalize02/23/08 http://bugs.python.org/issue2170created maltehelmert Add map, filter, zip to future_builtins 02/24/08 http://bugs.python.org/issue2171created georg.brandl Add doc-string to UserDict and DictMixin 02/24/08 http://bugs.python.org/issue2172created belopolsky patch Python fails silently on bad locale 02/24/08 http://bugs.python.org/issue2173created motteneder xml.sax.xmlreader does not support the InputSource protocol 02/24/08 http://bugs.python.org/issue2174created ygale Expat sax parser silently ignores the InputSource protocol 02/24/08 http://bugs.python.org/issue2175created ygale Undocumented lastrowid attribute i sqlite3 cursor class 02/24/08 http://bugs.python.org/issue2176created bukaj Update compiler module to handle class decorators02/24/08 CLOSED http://bugs.python.org/issue2177created therve patch Problems with Belarusian Latin locale02/24/08 http://bugs.python.org/issue2178created booxter with should be as fast as try/finally02/24/08 http://bugs.python.org/issue2179created jyasskin tokenize: mishandles line joining02/25/08 http://bugs.python.org/issue2180created jaredgrubb optimize out local variables at end of function 02/25/08 http://bugs.python.org/issue2181created nnorwitz patch, patch tokenize: does not allow CR for a newline
Re: [Python-Dev] download python-2.6 docs?
Neal Becker schrieb: http://docs.python.org/dev/download.html I want a pdf. The above link says: To download an archive containing all the documents for this version of Python in one of various formats, follow one of links in this table. But there are no links. Unfortunately, we haven't yet worked out a procedure to build downloadable packages for the development docs. I'll try to work on that this weekend. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Code freeze?
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2008, at 4:03 PM, Eric Smith wrote: Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote: Hey Barry! Hi Christian! When are you planing to freeze the code of the trunk and branches/py3k for the upcoming alpha releases? I'll merge the last modifications from 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking good, except for the two profile tests on 3.0. I'm going to test Windows later. Okay, let's go ahead and make it official. I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to that: 2200 UTC Friday 29-Feb-2008. Argh! I was going to check the last of the PEP 3127 changes in tonight, but I won't make it by 6 pm EST. I have them finished, but no tests written, so I'm not comfortable checking them in yet. I guess it's no big deal that they slip until the next alpha. Sorry, I notice my message might not have been clear. As of this writing, you have 23 hours and 54 minute before code freeze :). Code freeze: 2200 UTC 29-Feb-2008 Alpha making: 2300 UTC 29-Feb-2008 It turns out I'm not going to make this first alpha with the rest of the PEP 3127 changes. The code doesn't handle all combinations of (int, long) and (str, unicode). I'll get it finished before the next alpha. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code freeze?
Not speaking for Barry or anyone else but myself. This is an explanation of how I understand the process and why I welcome it. Scott Dial writes: I don't understand who these alpha releases are supposed to be for, and who they will serve. An alpha test is internal. It is comprised of those tests the developers working on the product (and/or an affiliated QA department) can imagine. Similarly, an alpha release is of, by, and for the developers. I'm not sure what developer outside of the core community would want to work with something missing key features and released fairly arbitrarily. Developers outside of the core community are not targeted. That said, how do you know that key features are missing? Part of the point of a release is that it says *this stuff* is working. I want *my* key feature to be part of this stuff, not *your* key feature. Given my feature, I download to give the team feedback as early as possible. Lacking yours, you don't. Next alpha, presumably our roles will be reversed. More to the point, I don't know why a developer wouldn't just checkout from SVN in any case. Certainly if they are going to help root out bugs, then we would like them to be using the trunk if possible. I fear that once an alpha is 2 weeks old, we will start saying please check if its still a problem on the trunk. Software development in practice is a matter of take two steps back, then three steps forward. The point of an alpha release is to checkpoint what is a regression, and what is a temporary feature introduced by new development. The latter is admissible on the trunk, but the goal should be none from one alpha to the next. In other words, a bug introduced by new development should be fixed by the next alpha. If it can't be, the developer misjudged the timing of the merge to mainline; it wasn't ready yet. A mild concern is how this effects checkins with individuals either trying to meet a deadline or even wait until after an alpha release to checkin a large change. I'm not sure this will happen, but having releases scheduled without feature milestones attached certainly changes the environment for work to be done in. Scheduling feature milestones assumes that people put priority on those features at a given time. Barry can't assume that yet. Once the rhythm is established, Barry can start asking for, and some people will start volunteering, milestone commitments for given releases. I think that it probably is desirable to to put that deadline pressure on. Individuals who rush to get their work in, and cause alpha-to- alpha regressions, can be advised to wait in the future in similar circumstances. Once the rhythm is established, people can expect that alphas will be consistently increasing in features and consistently decreasing in defects. If that's not true, something's wrong with the process, and the team needs to step back and do something about it. But in the nature of software development, *monotone improvement is not something you want to, or even can, impose on the trunk at all points in time*. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Code freeze?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 29, 2008, at 1:59 PM, Stephen J. Turnbull wrote: I think that it probably is desirable to to put that deadline pressure on. Individuals who rush to get their work in, and cause alpha-to- alpha regressions, can be advised to wait in the future in similar circumstances. Once the rhythm is established, people can expect that alphas will be consistently increasing in features and consistently decreasing in defects. If that's not true, something's wrong with the process, and the team needs to step back and do something about it. I agree, and what I already think is broken about our process is that changes can land that break the buildbots. Ideally, this should never happen, but our build/test environment has two flaws. First, it's retroactive not proactive. Second, the tests themselves are not always stable. Given the wide range of platforms and the volunteer nature of the buildbot farm, I don't think there's much right now that we can do about the second point. We can do things to mitigate it though, such as take a majority-success approach, or give more weight to more stable platforms and buildbots. The second one is tougher because more work on the process is necessary, and it would change our workflow for committing changes to the tree. Even with its faults, I'm a big fan of PQM https://launchpad.net/pqm though that's not something I think we're ready for. The bigger question though is whether we as a development community would change the way we work so that nothing lands if it doesn't pass all the tests. We'd be trading some inconvenience (and administrative headaches) for better overall quality and always-releasable guarantees. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8heD3EjvBPtnXfVAQIj/gP/dyf1oavy7y4gTrKHi+j/m+0y4DJstIDf Fh2MhqExWtCX6V8M3mOn46uRwStwtz9+TUEznNEC8xsxq734GtVyi9Vw6cLpmZQ6 uQp+IBT+nkqNz3sDd8N/ewAGPBO5Ml2m+yn+rfi2XaT5Vfi5akSR/aDwJKGC71fL 8IaWHo5XKEM= =JQMb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Code freeze?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 29, 2008, at 1:08 PM, Eric Smith wrote: Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2008, at 4:03 PM, Eric Smith wrote: Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote: Hey Barry! Hi Christian! When are you planing to freeze the code of the trunk and branches/py3k for the upcoming alpha releases? I'll merge the last modifications from 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking good, except for the two profile tests on 3.0. I'm going to test Windows later. Okay, let's go ahead and make it official. I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to that: 2200 UTC Friday 29-Feb-2008. Argh! I was going to check the last of the PEP 3127 changes in tonight, but I won't make it by 6 pm EST. I have them finished, but no tests written, so I'm not comfortable checking them in yet. I guess it's no big deal that they slip until the next alpha. Sorry, I notice my message might not have been clear. As of this writing, you have 23 hours and 54 minute before code freeze :). Code freeze: 2200 UTC 29-Feb-2008 Alpha making: 2300 UTC 29-Feb-2008 It turns out I'm not going to make this first alpha with the rest of the PEP 3127 changes. The code doesn't handle all combinations of (int, long) and (str, unicode). I'll get it finished before the next alpha. No problem Eric. You know when the next alpha is coming out anyway. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8hbrnEjvBPtnXfVAQKRvgP/Qe5/vCtHPX5LKklLTtcD4pnR/AtRs/V2 /VNeqkvXnr4Ooe8LwNKFMo4Yy0pdvjEQbLR/FGKojG2JIJ0kXyE2ObQXFsKCKAxV TCr8ZPeh5wqGLYuJAXtTz/UJzf5CzkgbKY9p32u5yy5qXiP7rgGpi8JvSZJKN3cP bApx/pGyNdU= =GaSZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
I'm going through the motions of getting my newly added build slave in a half decent state. I think the buildbot should have a name different from 'x86 XP'. (Martin, Neal?) Yeah, I've dropped Martin a note regarding this. The community bots refer to Windows Server 2003 boxes as just that, so perhaps a rename to 'x86 Windows Server 2008' is appropriate. FWIW as it's a 64-bit box, I'm hoping to get a slave set up for 'x64 Windows Server 2008' as well. I (now) see what you mean. I renamed it to x86 W2k8. (As far as I can see, the x64/x86 nature of the slave is dictated by the master, correct? i.e. I can't tweak/clone this myself?) Right. I can set up another slave, but would prefer to do so only after you got the first one running. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
I'm going through the motions of getting my newly added build slave in a half decent state. The external.bat and external-amd64.bat files needed the following in order to build db-4.4.20: I've fixed that in a different way. devenv.exe should not be used, as it is unavailable in VS Express. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
- vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static The upgrade is requires only once. It probably belongs next to the checkout or svn up and not in the build section. I came up with yet another solution: I changed the repository to contain already the converted files (or, rather, made a copy, as the 2.5 branch is still using the 7.1 project files):. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
I don't know how the existing vcbuild line ever worked, given the following output from vcbuild /?: Usage: vcbuild [options] [project|solution] [config|$ALL] It didn't. All the existing slaves already had a checkout when we switched to VS 2008, so a fresh checkout was never tested. That might also explain the buildbot crashes - they still were using object files from VS 2003, for db-4.4.20. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] No releases tonight
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I tried, I really did. Python 2.6 is nearly ready, I'm mostly trying to figure out how to build the web pages properly. I haven't started on 3.0, but huge thanks go to Brett Cannon, Neal Norwitz, Mark Dickinson, and Fred Drake for helping out tonight with everything, including fixing the outstanding bugs in 3.0. Python 2.6a1 is tagged and built, so feel free to commit changes to the trunk. Python 3.0 is not tagged yet so if you can hold off from committing to that branch for a little while longer, that would be appreciated. I will cut 3.0a3 tomorrow (Saturday) as early as possible. time-to-start-drinking-ly y'rs, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8jdyXEjvBPtnXfVAQJSowQAgIqqYKYPvzEMtvtAHiNC+OkMpO3vxelh 9kcAgXClhCS47wAMc9viJsb5Uo12f7TlOURkEjuMZ13jrBri+HCFtrAGjjHj/qHk KyH9ua+q0dCtpg0P0CzvxznGr7k2XV5LiZit4G+UwuSokJr/F/dUDQV3jkSgWEvh xTRj8ZZisQw= =Hg6S -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] No releases tonight
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I tried, I really did. Python 2.6 is nearly ready, I'm mostly trying to figure out how to build the web pages properly. I haven't started on 3.0, but huge thanks go to Brett Cannon, Neal Norwitz, Mark Dickinson, and Fred Drake for helping out tonight with everything, including fixing the outstanding bugs in 3.0. Python 2.6a1 is tagged and built, so feel free to commit changes to the trunk. Python 3.0 is not tagged yet so if you can hold off from committing to that branch for a little while longer, that would be appreciated. I will cut 3.0a3 tomorrow (Saturday) as early as possible. time-to-start-drinking-ly y'rs, Barry: If you can document the web stuff you have to do I will formalize it as a procedure for use in future releases. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
