Re: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for commit privs.
Hi there Hirokazu Yamamoto, Some of the other Python developers and myself are interested in knowing whether or not you'd like to become a Python committer. We've noticed you're very active in the issue tracker and you always seem to be able to provide patches when the VC6/VC8 Python builds break (Christian Heimes would like to nominate you as the maintainer for the VC6/VC8 builds). If you're interested all we need from you is a login name (i.e. hirokazu.yamamoto or yamamoto.hirokazu if you prefer), an e-mail address so you can be subscribed to python-committers, and an ssh public key. Instructions for generating a key can be found in the Python Developer FAQ: http://www.python.org/dev/faq/#how-do-i-generate-an-ssh-2-public-key (You can send your public key to Martin: [EMAIL PROTECTED]) Look forward to hearing from you. Thanks for your work with Python so far! Regards, Trent. > -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of Trent Nelson > Sent: 11 August 2008 20:28 > To: [email protected] > Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) > for commit privs. > > > What do people think about making Hirokazu Yamamoto a committer? I > rarely see any mailing list posts from him, but he sure makes up > for it in terms of patches submitted to the issue tracker. As far > as I can tell (I've noticed his regular involvement via patches and > whatnot for well over a year), he's a pretty switched on guy with a > lot of Windows experience -- every time trunk fails to build with > vc6/7/8, for example, he's got patches lined up. > > > Trent. > ___ > python-committers mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
darn. I was hoping to get a 2.5.3 rc and final out soon. Can anyone else build the binaries? On Tue, Aug 12, 2008 at 2:43 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> It sounds like Wednesday August 13th will not be feasible, so we'll do >> beta 3 on Wednesday August 20th. I've updated both the PEP and the >> Google Calendar. > > I'll be on vacation then, and not be able to produce Windows binaries > (until September 8) > > Regards, > Martin > ___ > python-committers mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-committers > > ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
I am planning to offer a single file patch for 2.3 and 2.4. As far as one more 2.5 release, I don't think there's going to be many changes to the 2.5 branch between now and 2.6/3.0 final - although if there is, we'll obviously have to do another release. I wouldn't be horribly surprised if more nasty lurking bugs remain in the C code. The google security review found a bunch, apple found some, but there's really quite a lot of code there... On Tue, Aug 12, 2008 at 4:28 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Anthony Baxter wrote: >> darn. I was hoping to get a 2.5.3 rc and final out soon. Can anyone >> else build the binaries? > > For the 2.5, the challenge is to produce AMD64 and Itanium binaries, > using vsextcomp (plus the usual problems of collecting all the > necessary packages and build them first). > > Are you also planning to produce a 2.4 security (source only) release? > Will the 2.5 release be the final bug fix release? > > Regards, > Martin > ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
-On [20080812 08:28], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote: >For the 2.5, the challenge is to produce AMD64 and Itanium binaries, >using vsextcomp (plus the usual problems of collecting all the >necessary packages and build them first). I have a Windows x64 box at home. Which Visual Studio was now needed, 2008? If you want Martin, we can go over making sure I got a build environment set up as well? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Sorrow paid for valour is too much to recall... ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
Anthony Baxter wrote: > I am planning to offer a single file patch for 2.3 and 2.4. As far as > one more 2.5 release, I don't think there's going to be many changes > to the 2.5 branch between now and 2.6/3.0 final - although if there > is, we'll obviously have to do another release. I would like to establish a tradition where, after some final bug fix release (e.g. for 2.5), further "mere" bug fixes are banned from the maintenance branch (and I did revert several bug fixes from the 2.4 branch). Only security-relevant patches would be allowed to the branch. >From such a branch, only source releases will be created, for a period of five years. So I would rather - declare that the next 2.5 release will be the final one, and that any bug fixes that are not security fixes must be committed now. I know some Linux distributors have patches that they still want to see integrated. - after some announcement of such an upcoming 2.5 release, create release candidate, release, documentation, and windows binaries. - also create a 2.4 release, as a source-only release (i.e. no documentation update or windows binaries) - leave 2.3 alone (it's more than 5 years since the initial 2.3 release) Realistically, I would schedule such a 2.5 release after 2.6 and 3.0 have been released (and indeed was planning to do so myself). If you feel the urgency of doing something now, how about *only* providing patches for 2.5 at the moment? ActiveState might integrate them into ActivePython; system vendors can also pick them up (if they haven't already). Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
Jeroen Ruigrok van der Werven wrote: > -On [20080812 08:28], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote: >> For the 2.5, the challenge is to produce AMD64 and Itanium binaries, >> using vsextcomp (plus the usual problems of collecting all the >> necessary packages and build them first). > > I have a Windows x64 box at home. Which Visual Studio was now needed, 2008? 2003, along with a platform SDK, and vsextcomp, and we would need both AMD64 and IA64 binaries (although it's probably ok if the Itanium binaries aren't tested as long as you can verify that they are IA64 binaries). > If you want Martin, we can go over making sure I got a build environment set > up as well? I'm leaving Sunday - not sure whether that's enough time to set things up. Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 12, 2008, at 2:54 AM, Anthony Baxter wrote: I am planning to offer a single file patch for 2.3 and 2.4. It shouldn't be hard to build source tarballs, though I also don't know if it's worth it. We should leave the option open if there's demand. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKF2nnEjvBPtnXfVAQL2CAP+NKyc63DyNwCE3iopBJU/u1LjpZ/TT1H+ ujzPVB/f/QtoXiFp+fRbWK0HTn9u1t7ts0R/FMgxop66BQB8lAqWVDY+D8WBM3It DcO10GWWd4oLezfi346tqru7DqwoPOlXzy3e6esliEBg/1SCiZMB8BPVZinJFSvk njPAK5VkWeo= =1cm8 -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 12, 2008, at 3:38 AM, Martin v. Löwis wrote: Anthony Baxter wrote: I am planning to offer a single file patch for 2.3 and 2.4. As far as one more 2.5 release, I don't think there's going to be many changes to the 2.5 branch between now and 2.6/3.0 final - although if there is, we'll obviously have to do another release. I would like to establish a tradition where, after some final bug fix release (e.g. for 2.5), further "mere" bug fixes are banned from the maintenance branch (and I did revert several bug fixes from the 2.4 branch). I'm not sure I agree with this policy. Can you elaborate on /why/ you want this? I understand that we're a volunteer organization, and that our resources are limited. I'm also wary about siphoning off those limit resources right now for working on other than 2.6 and 3.0, but I'm not sure that this policy really buys us much there. E.g. with this policy you'll need a release cop to patrol commits and back out non-security fixes right away. It's much more work to revert such changes whenever we get around to doing the release. Seems like it could be /more/ work with this policy. I do agree that we need to be very careful about introducing new features, but I think non-security patches can be okay. I had some 2.4 patches backed out because they weren't security releases. I was okay with it at the time, but I'm uncomfortable about imposing this as a general rule. If we have bugs, and we have someone motivated to fix them, we should opt toward fixing them. It's demoralizing to have one's patches backed out. Besides, we still have downstream vendors that are maintaining and releasing Python 2.4; does this mean they're out of luck for bug fixes or they have to roll their own? We're on an 18 month release schedule, which is a long time to wait, so I'm not in favor of an arbitrary date for cutting off "mere" bug fixes. Rather, I'd like to see a policy (but not a promise) of supporting two releases at a time. Thus, when 2.6 is released, we would stop support for all but critical security fixes for 2.4, but we could (not will) still release bug fixes for 2.5. And of course, we'll support 2.6/3.0 while 2.7/3.1 is being developed. Having lockstep 2.x and 3.x release complicates things a bit, but because they are lockstep, I'm thinking of them more as the same release rather than separate ones. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKF/jnEjvBPtnXfVAQIQdAQArojNCP9pEwrNxxYQgky5j36nO9buQlP2 c43AmS0xCa+OKK/fL1QEcza1n6B7j1fT/w6Cf429Rtdsh9tNwig5NVJDTuD/5rRg RXNJiBKsr69uba8ITV/qO8J1hEuew15w6exBXOMnAUpdoXpxafqg2ycoFmK3/C6E ZAXnDYAgFoc= =pkeW -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
I'll put my hand up for doing the Windows build as well (the x64 buildbot has all the necessary bits and pieces installed). I know some HP people that I could rope in to install the resulting IA64 build and run rt.bat. We're not shipping PGO builds for 2.5.x are we? Martin, not sure if you've had a chance to do anything with the VeriSign certificates? (Ambiguous question mark intended ;-) Trent. > -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of "Martin v. Löwis" > Sent: 12 August 2008 08:43 > To: Jeroen Ruigrok van der Werven > Cc: [email protected] > Subject: Re: [python-committers] [Python-Dev] next beta > > Jeroen Ruigrok van der Werven wrote: > > -On [20080812 08:28], "Martin v. Löwis" ([EMAIL PROTECTED]) > wrote: > >> For the 2.5, the challenge is to produce AMD64 and Itanium > binaries, > >> using vsextcomp (plus the usual problems of collecting all the > >> necessary packages and build them first). > > > > I have a Windows x64 box at home. Which Visual Studio was now > needed, 2008? > > 2003, along with a platform SDK, and vsextcomp, and we would need > both > AMD64 and IA64 binaries (although it's probably ok if the Itanium > binaries aren't tested as long as you can verify that they are IA64 > binaries). > > > If you want Martin, we can go over making sure I got a build > environment set > > up as well? > > I'm leaving Sunday - not sure whether that's enough time to set > things up. > > Regards, > Martin > ___ > python-committers mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
Martin v. Löwis wrote: If you feel the urgency of doing something now, how about *only* providing patches for 2.5 at the moment? ActiveState might integrate them into ActivePython; system vendors can also pick them up (if they haven't already). I *could* integrate patches into an ActivePython release. But I've found that there is value in having ActivePython using (mostly) the exact same sources as a python.org release. Depends on the patches, I guess. Trent -- Trent Mick trentm at activestate.com ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
>>> I am planning to offer a single file patch for 2.3 and 2.4. As far as >>> one more 2.5 release, I don't think there's going to be many changes >>> to the 2.5 branch between now and 2.6/3.0 final - although if there >>> is, we'll obviously have to do another release. > >> I would like to establish a tradition where, after some final bug fix >> release (e.g. for 2.5), further "mere" bug fixes are banned from the >> maintenance branch (and I did revert several bug fixes from the 2.4 >> branch). > > I'm not sure I agree with this policy. Can you elaborate on /why/ you > want this? Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better. An alternative would be to keep all infrastructure up and running, but that is infeasible. > I understand that we're a volunteer organization, and that our resources > are limited. I'm also wary about siphoning off those limit resources > right now for working on other than 2.6 and 3.0, but I'm not sure that > this policy really buys us much there. E.g. with this policy you'll need > a release cop to patrol commits and back out non-security fixes right > away. That's not necessary. When I made 2.3.7 and 2.4.5, I went through the complete log, and posted a list of patches that I wanted to revert. This was little effort, and I'm sure it would have been even less effort if people had known that 2.4.x is a closed branch. > It's much more work to revert such changes whenever we get around > to doing the release. Seems like it could be /more/ work with this policy. It wasn't really that much work - there were little non-security patches, and they were easily identifiable from the commit message. > I do agree that we need to be very careful about introducing new > features, but I think non-security patches can be okay. They aren't, as they don't get sufficient testing. > It's > demoralizing to have one's patches backed out. Besides, we still have > downstream vendors that are maintaining and releasing Python 2.4; does > this mean they're out of luck for bug fixes or they have to roll their own? I've talked to the downstream vendors, and they really want security patches for a long time, above all. They are fine with maintaining their own patches (which they do, anyway). > We're on an 18 month release schedule, which is a long time to wait, so > I'm not in favor of an arbitrary date for cutting off "mere" bug fixes. > Rather, I'd like to see a policy (but not a promise) of supporting two > releases at a time. I think this requires more resources than we have - especially with your way of counting: > Thus, when 2.6 is released, we would stop support > for all but critical security fixes for 2.4, but we could (not will) > still release bug fixes for 2.5. And of course, we'll support 2.6/3.0 > while 2.7/3.1 is being developed. So that's *three* branches that we need to maintain, right: 2.5, 2.6, and 3.0. Once 3.1 is released, I supposed it's even *four* branches: 2.6, 2.7, 3.0, and 3.1. That means that every change must be committed/merged four times, you need to run the test suite four times, and so on. Depending on the nature of the bug fix, you also need to keep the specifics of the four branches in mind. I don't think our committers will accept such a work load - which means that some patches don't get backported (arbitrarily, depending on how relevant the committer views that policy). > Having lockstep 2.x and 3.x release complicates things a bit, but > because they are lockstep, I'm thinking of them more as the same release > rather than separate ones. I think this is an illusion. When did you last commit something to the trunk, and forward-ported it to the 3.0 branch? When did you last run "svnmerge avail"? Porting patches between 2.6 and 3.0 is anything but trivial. Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
> I'll put my hand up for doing the Windows build as well (the x64 > buildbot has all the necessary bits and pieces installed). I know > some HP people that I could rope in to install the resulting IA64 > build and run rt.bat. Notice that we both look for somebody to build the next 2.6/3.0 betas (see the subject), and the 2.5.3 rc and final release (assuming Anthony still has that plan). My testing on Itanium is the mere "does it install?", "can I start both cmdline and IDLE?", "is the help file the right one?". The test suite itself will fail/hang - it always did in 2.5.x. > We're not shipping PGO builds for 2.5.x are we? No. I don't think VS 2003 supported that. I don't do PGO for the AMD64 build of 2.6/3.0, either, because I also have a cross-compilation environment which prevents that. > Martin, not sure if you've had a chance to do anything with the > VeriSign certificates? (Ambiguous question mark intended ;-) Please see the most recent MSI files - they are all signed. Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for commit privs.
Thank you for sweet invitation, python committers! >We've noticed you're very active in the issue tracker and you always seem >to be able to provide patches when the VC6/VC8 Python builds break >(Christian Heimes would like to nominate you as the maintainer for the >VC6/VC8 builds). Yes, I have VC6, but I don't have VC8. It is true that the change required for VC6 is often required for VC8 too, but I cannot test VC8 directly. Are you OK about it? >If you're interested all we need from you is a login name (i.e. >hirokazu.yamamoto or yamamoto.hirokazu if you prefer), an e-mail >address so you can be subscribed to python-committers, and an ssh >public key. Instructions for generating a key can be found in the >Python Developer FAQ: I prefer hirokazu.yamamoto (hirokazu is given name, yamamoto is family name) Please use [EMAIL PROTECTED] as email address. I'll send SSH public key to MvL. Thank you. ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for commit privs.
On Tue, Aug 12, 2008 at 11:01 AM, Hirokazu Yamamoto <[EMAIL PROTECTED]> wrote: > Thank you for sweet invitation, python committers! > [SNIP] > Please use [EMAIL PROTECTED] as email address. You have now been subscribed, Hirokazu. -Brett ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
