Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
Is there a PEP with end-of-life info? I had meant to write a PEP on security releases for several years now. Since this still doesn't exist, here is the outline of the procedures that maintainers have agreed upon: - bug fix releases are made until the next feature release is out (with 2.7 being an exception from that rule) - security fixes are being provided until 5 years after the initial release of the feature release * for 2.6, this will be until Oct 1, 2013 * for 3.1, this will be until July 27, 2014 * for 3.2, this will be until Feb 20, 2016 The 5 years horizon is based on requests of system packagers (Linux distributions in particular), who often also have 5-year cycles for long-term support. - security releases are made whenever maintainers deem it necessary; the two options are * commit fixes into source repository only, and release whenever enough time has passed, or enough changes have accumulated, or * release right after a security issue has been resolved Which of these to take depends on the nature of the fix, of course. The former is intended for system packagers of Python - they can incorporate fixes that are official already despite not having been released yet. I'm not aware of a formal policy for 2.7. I guess it will end its life by BDFL pronouncement; giving it a 5 year bug fix period (which would end on July 3, 2015) seems a bit long to me - I'd favor to stop bug fixing along with the 3.4 release. The last BDFL decision (that I'm aware of) is that 2.7 should be supported "indefinitely", which is not "infinitely". Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
On 10/01/2012 01:30 PM, "Martin v. Löwis" wrote: Is there a PEP with end-of-life info? I had meant to write a PEP on security releases for several years now. Since this still doesn't exist, here is the outline of the procedures that maintainers have agreed upon: - bug fix releases are made until the next feature release is out (with 2.7 being an exception from that rule) - security fixes are being provided until 5 years after the initial release of the feature release * for 2.6, this will be until Oct 1, 2013 * for 3.1, this will be until July 27, 2014 * for 3.2, this will be until Feb 20, 2016 The 5 years horizon is based on requests of system packagers (Linux distributions in particular), who often also have 5-year cycles for long-term support. - security releases are made whenever maintainers deem it necessary; the two options are * commit fixes into source repository only, and release whenever enough time has passed, or enough changes have accumulated, or * release right after a security issue has been resolved Which of these to take depends on the nature of the fix, of course. The former is intended for system packagers of Python - they can incorporate fixes that are official already despite not having been released yet. I'm not aware of a formal policy for 2.7. I guess it will end its life by BDFL pronouncement; giving it a 5 year bug fix period (which would end on July 3, 2015) seems a bit long to me - I'd favor to stop bug fixing along with the 3.4 release. The last BDFL decision (that I'm aware of) is that 2.7 should be supported "indefinitely", which is not "infinitely". I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1. Georg ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
Le lundi 01 octobre 2012 à 13:30 +0200, "Martin v. Löwis" a écrit : > I'm not aware of a formal policy for 2.7. I guess it will end its life > by BDFL pronouncement; giving it a 5 year bug fix period (which would > end on July 3, 2015) seems a bit long to me - I'd favor to stop bug > fixing along with the 3.4 release. "5 years" was once recorded in the 2.7 release page: http://mail.python.org/pipermail/python-list/2010-April/573621.html ... although it isn't anymore: “Python 2.7 is scheduled to be the last major version in the 2.x series before it moves into an extended maintenance period.” http://www.python.org/download/releases/2.7/ Benjamin is the 2.7 release manager (good choice on his part ;-)), and on this thread he seems to be of the advice that 5 years is the number. Perhaps we can relax the 2.7 bugfix policy a bit: bugfix releases are made for 5 years, but core developers are free not to port minor bugfixes if they want to save up some time. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] contributor forms (was Re: contributor form for Alexander Belopolsky)
Unfortunately, the list of core developers with the form flag set doesn't match the actual forms on file. For example, I did not find my form in the files sent to me by the previous Administrator. I'm currently in the process of having all the forms scanned. I'll then check them into the PSF repository, along with the ones received by fax over the past couple of years. Once that's done, we can address any missing forms. KBK On Sat, Sep 29, 2012, at 12:51 PM, Chris Jerdonek wrote: > On Fri, Sep 21, 2012, Jesús Cea Avión wrote: > > > > Alexander Belopolsky is a core developer but the bugtracker doesn't [edit: > > but now does] > > have a "contributor form received" flag for him? > > FWIW, you can see a list of all such core developers using this URL: > > http://bugs.python.org/user?iscommitter=1&contrib_form=0&@action=search&@sort=username&@pagesize=300 > > There are currently 35 without a contributor form (though I realize > that many of them may not currently be active). > > --Chris > ___ > 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] Branches support status (Re: 3.3 branch created in main repository)
On Oct 01, 2012, at 02:23 PM, Georg Brandl wrote: >I've now added lifespan information to the 3.2 and 3.3 release schedule >PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1. Done for PEP 361, which actually covers both the 2.6 and 3.0 releases. I've described Python 3.0 as not being maintained for any purpose. Cheers, -Barry ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
On Oct 01, 2012, at 01:30 PM, Martin v. Löwis wrote: >I had meant to write a PEP on security releases for several >years now. +1 >Since this still doesn't exist, here is the outline >of the procedures that maintainers have agreed upon: >- bug fix releases are made until the next feature release is > out (with 2.7 being an exception from that rule) >- security fixes are being provided until 5 years after the initial > release of the feature release > * for 2.6, this will be until Oct 1, 2013 > * for 3.1, this will be until July 27, 2014 > * for 3.2, this will be until Feb 20, 2016 > The 5 years horizon is based on requests of system packagers > (Linux distributions in particular), who often also have 5-year > cycles for long-term support. >- security releases are made whenever maintainers deem it necessary; > the two options are > * commit fixes into source repository only, and release whenever > enough time has passed, or enough changes have accumulated, or > * release right after a security issue has been resolved > Which of these to take depends on the nature of the fix, of course. > The former is intended for system packagers of Python - they can > incorporate fixes that are official already despite not having been > released yet. The only thing missing is whether releases are made source-only or with binary packages for Windows and Mac. My understanding is that once a release goes into security-only mode, binary releases cease. Cheers, -Barry ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
On Oct 01, 2012, at 02:44 PM, Antoine Pitrou wrote: >"5 years" was once recorded in the 2.7 release page: >http://mail.python.org/pipermail/python-list/2010-April/573621.html > >... although it isn't anymore: >“Python 2.7 is scheduled to be the last major version in the 2.x series >before it moves into an extended maintenance period.” >http://www.python.org/download/releases/2.7/ > >Benjamin is the 2.7 release manager (good choice on his part ;-)), and >on this thread he seems to be of the advice that 5 years is the number. > >Perhaps we can relax the 2.7 bugfix policy a bit: bugfix releases are >made for 5 years, but core developers are free not to port minor >bugfixes if they want to save up some time. I think we should make a formal commitment to 2.7's lifespan, whatever that would be. When discussions about Python 2's ultimate demise come up, we should be able to point to the PEP for the official declaration, since once Python 2.7 maintenance ends, so does effectively Python 2's lifespan. the-champagne-is-cooling-as-we-speak-ly y'rs, -Barry ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
On 10/1/2012 8:23 AM, Georg Brandl wrote: On 10/01/2012 01:30 PM, "Martin v. Löwis" wrote: Is there a PEP with end-of-life info? I had meant to write a PEP on security releases for several years now. Since this still doesn't exist, here is the outline of the procedures that maintainers have agreed upon: - bug fix releases are made until the next feature release is out (with 2.7 being an exception from that rule) - security fixes are being provided until 5 years after the initial release of the feature release * for 2.6, this will be until Oct 1, 2013 * for 3.1, this will be until July 27, 2014 * for 3.2, this will be until Feb 20, 2016 The 5 years horizon is based on requests of system packagers (Linux distributions in particular), who often also have 5-year cycles for long-term support. - security releases are made whenever maintainers deem it necessary; the two options are * commit fixes into source repository only, and release whenever enough time has passed, or enough changes have accumulated, or * release right after a security issue has been resolved Which of these to take depends on the nature of the fix, of course. The former is intended for system packagers of Python - they can incorporate fixes that are official already despite not having been released yet. I'm not aware of a formal policy for 2.7. I guess it will end its life by BDFL pronouncement; giving it a 5 year bug fix period (which would end on July 3, 2015) seems a bit long to me - I'd favor to stop bug fixing along with the 3.4 release. The last BDFL decision (that I'm aware of) is that 2.7 should be supported "indefinitely", which is not "infinitely". I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1. Someone recently said they could not find life-cycle information on python.org. I think it would be good to have one PEP or website page that has the general policy, given above by Martin, the exception for 2.7, and a summary table with one line per release (back to say, 2.5), giving number and date for Initial release Last bug fix release Last security release ... 3.3.0 2012 Sep 30 (2014 ???)(2017 Sep) (tentative dates in parens) Terry ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.3.1 two months away?
On 10/1/2012 1:02 AM, Georg Brandl wrote: You are right that we should have information about bugfix/security mode and about end-of-life; I propose to put them in the respective release schedule PEPs. From the commit: > +3.3 will receive bugfix updates approximately every 4-6 months until > +3.3.1 schedule > +-- > + > +- 3.3.1 beta 1: planned for Oct/Nov 2012 I presume you see a number of little fixes coming that should not too long. I almost missed this ;-). Terry ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.3.1 two months away?
On Mon, 01 Oct 2012 10:57:45 -0400, Terry Reedy wrote: > On 10/1/2012 1:02 AM, Georg Brandl wrote: > > > You are right that we should have information about bugfix/security mode > > and > > about end-of-life; I propose to put them in the respective release schedule > > PEPs. > > From the commit: > > > +3.3 will receive bugfix updates approximately every 4-6 months until > > > +3.3.1 schedule > > +-- > > + > > +- 3.3.1 beta 1: planned for Oct/Nov 2012 > > I presume you see a number of little fixes coming that should not too > long. I almost missed this ;-). I believe Georg is basing this on past experience, both ours and the general software community...the users *always* find nasty bugs only after the first production release :) I have some hope we did a little better this time, though. Judging by the bug reports we got a bunch of pre-testing from both the Gentoo team and Ubuntu, and I'm pretty sure their testing has been more extensive this time than it was for previous 3.x releases. On the other hand, Gentoo (Arfrever) already found one crasher post-release...but fortunately it only happens in debug builds (although that could mean there is a behavior bug in non-debug builds). --David ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.3.1 two months away?
On 10/01/2012 04:57 PM, Terry Reedy wrote: On 10/1/2012 1:02 AM, Georg Brandl wrote: You are right that we should have information about bugfix/security mode and about end-of-life; I propose to put them in the respective release schedule PEPs. From the commit: > +3.3 will receive bugfix updates approximately every 4-6 months until > +3.3.1 schedule > +-- > + > +- 3.3.1 beta 1: planned for Oct/Nov 2012 I presume you see a number of little fixes coming that should not too long. I almost missed this ;-). No, in fact we have a security fix in the pipeline; the point releases for all branches will come out when the respective patch is finished. That we can quickly fix not-so-critical but annoying bugs found by users in 3.3.0 is a nice side-effect. cheers, Georg ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.3.1 two months away?
2012/10/1 R. David Murray : > On the other hand, Gentoo (Arfrever) already found one crasher > post-release...but fortunately it only happens in debug builds (although > that could mean there is a behavior bug in non-debug builds). It definitely happens in release builds. -- Regards, Benjamin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.3.1 two months away?
On 10/01/2012 07:30 PM, Benjamin Peterson wrote: 2012/10/1 R. David Murray : On the other hand, Gentoo (Arfrever) already found one crasher post-release...but fortunately it only happens in debug builds (although that could mean there is a behavior bug in non-debug builds). It definitely happens in release builds. I guess you're talking about the *second* crasher :| Georg ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
2012/10/1 Georg Brandl : > I've now added lifespan information to the 3.2 and 3.3 release schedule > PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1. I just updated the 3.1 and 2.7 schedules. -- Regards, Benjamin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/10/12 14:23, Georg Brandl wrote: > I've now added lifespan information to the 3.2 and 3.3 release > schedule PEPs, perhaps Barry and Benjamin could do the same for > 2.6 to 3.1. http://python.org/dev/peps/pep-0398/ """ 3.3 Lifespan 3.3 will receive bugfix updates approximately every 4-6 months until one release after the release of 3.4.0 final. After that, security updates (source only) will be released until 5 years after the release of 3.3.0 final, which will be September 2017. """ I am not a native english speaker, but I guess the intention is to do a final bugfix release for 3.3 after 3.4.0 is out, before moving 3.3 to "security fixes only". Could you possibly clarify the wording in the PEP?. Sorry if I am being a pain :). - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQCVAwUBUGoqJZlgi5GaxT1NAQKYkwP/VLbum1YCj6aTxPQdFUMem+M6J/s/RcBD 89xYq9Ll5B1km2P+xDJqf4P6HnLObtOr9jflWui4LwLVt3uOzCb77f8jUQ9/7IVR AU6QwhIgcmPnlxZgROSXUHvJ3abgXtK6tqyniGxQRs9s1Ao6At5wniZnDYChvfrV KQA4+uq7u/o= =/11g -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
On Tue, 02 Oct 2012 01:41:25 +0200, Jesus Cea wrote: > On 01/10/12 14:23, Georg Brandl wrote: > > I've now added lifespan information to the 3.2 and 3.3 release > > schedule PEPs, perhaps Barry and Benjamin could do the same for > > 2.6 to 3.1. > > http://python.org/dev/peps/pep-0398/ > > """ > 3.3 Lifespan > > 3.3 will receive bugfix updates approximately every 4-6 months until > one release after the release of 3.4.0 final. After that, security > updates (source only) will be released until 5 years after the release > of 3.3.0 final, which will be September 2017. > """ > > I am not a native english speaker, but I guess the intention is to do > a final bugfix release for 3.3 after 3.4.0 is out, before moving 3.3 > to "security fixes only". Could you possibly clarify the wording in > the PEP?. As a native English speaker it is not immediately obvious to me how to make that clearer. Is it that the antecedent of "one release" isn't clear? --David ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/12 02:25, R. David Murray wrote: >> 3.3 will receive bugfix updates approximately every 4-6 months >> until one release after the release of 3.4.0 final. After that, >> security [...] > As a native English speaker it is not immediately obvious to me > how to make that clearer. Is it that the antecedent of "one > release" isn't clear? I naivelly interpret "until one release after the release of 3.4.0" as talking about doing another 3.4 release. I find it ambiguous about what branch we are talking about. Maybe something in the line of "the last bugfix release of 3.3 will be done after 3.4.0 is published". Or "After 3.4.0 is released, we will release a final bugfix release of 3.3". - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQCVAwUBUGo3Nplgi5GaxT1NAQLl+AP/b3WMlDD6StHE9QCya5GTdz6pukBCXXf+ y+c9/lXVI+6ORFX0z+cp9DwOX9PhHP47JDJaryog/s7tAhQQ9/eCrvjM3iaXRwtM hPby1nZNfnXU54vyGKvNJCrMHSYw70vOyV3hhCOGDgBz7OsF7C3dXGTLEoPBUEz+ OSmrFcYhADU= =3CrX -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)
On 10/02/2012 02:37 AM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/12 02:25, R. David Murray wrote: 3.3 will receive bugfix updates approximately every 4-6 months until one release after the release of 3.4.0 final. After that, security [...] As a native English speaker it is not immediately obvious to me how to make that clearer. Is it that the antecedent of "one release" isn't clear? I naivelly interpret "until one release after the release of 3.4.0" as talking about doing another 3.4 release. I find it ambiguous about what branch we are talking about. Maybe something in the line of "the last bugfix release of 3.3 will be done after 3.4.0 is published". Or "After 3.4.0 is released, we will release a final bugfix release of 3.3". I've tried to reword it now. Georg ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
