Re: [python-committers] Transfer of power
As someone who's not been involved for some time now, but was release manager for a three or four years (2.3.1 through to 2.5.1), trying to have the release manager also be a decider of potentially controversial things doesn't seem scalable. Getting a release out is a heck of a lot of work, both the actually cutting the alphas, betas, &c, and also triaging issues that comes up and chasing people up for fixes. I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager. On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann wrote: > Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400: > > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou > wrote: > > > > > > > > > I'd like to point out that the N-virate idea doesn't handle a key > issue: > > > once you have a N-virate, how do you evolve its composition according > to > > > the implication and motivation of its members - but also to remarks or > > > frustation by non-virate contributors (especially new contributors who > > > will feel there's a perpetual category they're locked out of)? Do you > > > just wait for people to gently step down when required? > > > > One way would be to re-elect them every 5 or so years. Essentially, > > an N-virate is a dictator-like entity for a few years. > > > > Yury > > We've had good luck in the OpenStack community tying leadership to > release cycles. It causes elections more often (our cycles are 6 > months long), but people tend to step up for several cycles in a > row so that hasn't been a cause of excessive turnover. Having > frequent opportunities for folks to step down gracefully when they > need or want to also means no one feels like they are signing up > for an indefinite time commitment. > > For a multi-person group, staggered elections where only a portion > of the group is up for election at one time, also provides some > consistency when there is turnover. > > Doug > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: PEP 563 and Python 3.10.
While I have not been involved in the release process for like 15 years or more, I would like to point out that breaking changes mean the distros are less likely to ship them, and be less likely to trust updates. Trying to get RH &c to stop shipping 1.5.2 was a huge effort. Always, any time when you might need to break compat it's a huge risk. On Wed, 21 Apr 2021, 4:58 am Thomas Wouters, wrote: > > (Starting a new thread so as not to derail any of the ongoing discussions.) > > Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP > 563 (postponed evaluation of annotations) becoming the default. The > Steering Council has considered the issue carefully, along with many of the > proposed alternatives and solutions, and we’ve decided that at this point, > we simply can’t risk the compatibility breakage of PEP 563. We need to roll > back the change that made stringified annotations the default, at least for > 3.10. (Pablo is already working on this.) > > To be clear, we are not reverting PEP 563 itself. The future import will > keep working like it did since Python 3.7. We’re delaying making PEP 563 > string-based annotations the default until Python 3.11. This will give us > time to find a solution that works for everyone (or to find a feasible > upgrade path for users who currently rely on evaluated annotations). Some > considerations that led us to this decision: > > - PEP 563’s default change is clearly too disruptive to downstream users > and third-party libraries to happen right now. We can’t risk breaking even > a small subset of the FastAPI/pydantic users, not to mention other uses of > evaluated type annotations that we’re not aware of yet. > - PEP 563 provides no warning to users of the feature it’s disabling. > Without that, we can’t expect users to be aware of the upcoming breakage. > The lack of a warning was by design, and made sense in a world where type > annotations were only consumed by static type checkers --- but that’s not > actually the situation we’re in. There are clearly existing real-world, > run-time uses of type annotations that would be adversely affected by this > change. > - Originally, PEP 563 was scheduled to take effect in Python 4, and this > changed recently (after the discussion in the Language Summit of 2020). > It's possible that third-party libraries and users didn’t plan to react in > the current time frame as they were not aware of this change in timing. > - There isn’t enough time to properly discuss PEP 649 or any of the > alternatives before the beta 1 deadline, and we really need to make sure we > don’t compound errors here. We need to look for a long term solution, > which isn’t possible while still maintaining the release deadlines of > Python 3.10. That means we’re also deferring PEP 649 to Python 3.11. > > In the Steering Council’s unanimous opinion, rolling back the default flip > for stringified annotations in Python 3.10 is the least disruptive of all > the options. > > We need to continue discussing the issue and potential solutions, since > this merely postpones the problem until 3.11. (For the record, postponing > the change further is not off the table, either, for example if the final > decision is to treat evaluated annotations as a deprecated feature, with > warnings on use.) > > For what it’s worth, the SC is also considering what we can do to reduce > the odds of something like this happening again, but that’s a separate > consideration, and a multi-faceted one at that. > > For the Steering Council, > Thomas. > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/ULSWULZIBTYQ5GRBTLRQGNKQ525S7WJC/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Proposed tiered platform support
I wonder if putting this into a PEP might be a little heavyweight in terms of making adjustments to the platform triples and their priorities? I perhaps think something that's a look aside table with a defined policy of how to move various triples up and down might work better? On Fri, 11 Mar 2022, 10:36 am Brett Cannon, wrote: > I brought this up on python-dev at > https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ > , and the feedback seemed supportive. As such, I am bringing a draft of > what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders > for people to help me fill in to see how this will look overall. > > For any platform(s) you support, please reply with any relevant details > that should be added to the relevant tables below. Once I have these > details I will loop back with the proposed update to PEP 11 and make sure > everyone is still on board with the proposal. > > = > Tiers > = > > Tier 1 > == > > - `Test suite failures < > https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__ > block releases. > - Changes which would break the ``main`` branch are not allowed to be > merged; > any breakage may be reverted immediately. > - All core developers are responsible to keep these platforms working. > - Promotion of this tier requires consensus/SC approval. > > === = > Target Triple Notes > === = > i686-windows-msvc > x86_64-windows-msvc > x86_64-apple-darwin macOS 11 > x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_ > === = > > .. [ubuntu-20_01] > https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4 > > > Tier 2 > == > > - Must have a stable buildbot. > - At least **two** core developers are signed up to support the platform. > - Changes which break any of these platforms are to be reverted within 24 > hours. > - Failures of these platforms block a release. > - Promotion of this tier requires consensus/SC approval. > > == == > == > Target Triple Notes Buildbot > Contacts > == == > == > aarch64-apple-darwin XXX > https://buildbot.python.org/all/#/builders/725 XXX > aarch64-linux-gnu glibc XXX [fedora-stable]_ > https://buildbot.python.org/all/#/builders/125 XXX >glibc 2.28 [RHEL8]_ > https://buildbot.python.org/all/#/builders/529 XXX > aarch64-windows-msvc XXX > https://buildbot.python.org/all/#/builders/729 XXX > powerpc64-linux-gnuglibc XXX > https://buildbot.python.org/all/#/builders/237 XXX > powerpcle-linux-gnuglibc XXX > https://buildbot.python.org/all/#/builders/90 XXX > s309x-linux-gnuglibc XXX > https://buildbot.python.org/all/#/builders/223 XXX >glibc 2.28 [RHEL8]_ > https://buildbot.python.org/all/#/builders/509 XXX >glibc 2.17 [RHEL7]_ > https://buildbot.python.org/all/#/builders/179 XXX > x86_64-linux-gnu glibc 2.17 [RHEL7]_ > https://buildbot.python.org/all/#/builders/15 XXX > x86_64-unknown-freebsd XXX > https://buildbot.python.org/all/#/builders/172 XXX > == == > == > > .. [fedora-stable] XXX > .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8 > .. [RHEL7] > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/sect-red_hat_enterprise_linux-7.0_release_notes-compiler_and_tools-glibc > > > Tier 3 > == > > - Must have a stable buildbot. > - Code may be checked into ``main`` for the platform. > - At least **one** core developer is signed up to support the platform. > - Test failures do **not** block releases. > - Promotion to this tier is self-service. > > = == > == > Target Triple Notes Buildbot > Contacts > = == > == > wasm32-unknown-emscripten XXXXXX > Brett Cannon, Christian Heimes > wasm32-unknown-wasi XXXXXX > Brett Cannon, Christian Heimes > = == > == > > > All other platforms > === > > - Only code which either supports a higher-tier platform or is a general > improvement may be checked in. > ___ > python-committers mailing list -- python-committers@pytho
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 > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > > ___ python-committers mailing list python-committers@python.org 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 python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] ubuntu release plan
What would this professionalisation get us that we don't have now? As far as I can see, the biggest hole at the moment (as always) is with people to trawl the tracker and triage bug reports and patches. On Fri, Aug 15, 2008 at 8:35 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Antoine Pitrou wrote: >> >> Ubuntu's sophisticated release plan is certainly justified by its >> business model, and the desire to both appeal to the open source people >> and the corporate people without creating two different distributions. >> >> I don't think Python has the same business requirements (neither does it >> have marketing and commercial teams), and having differentiated releases >> sounds like unwarranted complication. > > IMHO the PSF and Python core development crew doesn't have a business plan > at all. By business plan I'm referring to making money with Python directly. > As far as I know most core developers are working on Python beause it's fun. > Some developers like Guido are paid by their employers to work on Python as > part of their job. > > Just a crazy idea ... Maybe it's time to make the next step toward > professionalizing Python. Python is more and more becoming important for > companies. They have to rely upon a stable and solid Python interpreter. > Perhaps some companies are willing to pay the PSF. In return the PSF could > hire some developer to work on Python full time. A couple of months ago one > well known core developer expressed his interest in a paid job. A crew of > three to four full time developers could make a huge difference. > >> Just my two non-Canonical cents of course! > > Nice pun :) > > Christian > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Cutting Python 2.6
If there's a screwup, and you need to recut the branch, you want to be sure someone else hasn't been helpful and added something else to the repo. On Thu, Oct 2, 2008 at 9:37 AM, Jesus Cea <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Barry Warsaw wrote: >> IIUC, the critical bottleneck is tagging the tree, so the RM needs to >> make it far enough through the PEP to get to that point. Of course that >> does mean freezing the tree, and I don't think it's too difficult to do >> that. > > I always found strange the need to freeze the tree. When a svn tag is > created, the build process should use that tag to extract the files and > build the release, while the repository is being updated normally. > > In fact in a *.0 release, the tag should be a branch actually. > > Sure I'm missing something... > > - -- > Jesus Cea Avion _/_/ _/_/_/_/_/_/ > [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.8 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF > cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp > sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG > SNs5cVMhe7g= > =VRp9 > -END PGP SIGNATURE- > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Cutting Python 2.6
Sure, but that's more fiddly. From experience, when you're cutting releases, making things as simple as possible is a good thing. On Thu, Oct 2, 2008 at 11:35 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > There should be a way to re-tag only the file(s) that contain the fix. > > On Wed, Oct 1, 2008 at 4:00 PM, Anthony Baxter <[EMAIL PROTECTED]> wrote: >> If there's a screwup, and you need to recut the branch, you want to be >> sure someone else hasn't been helpful and added something else to the >> repo. >> >> >> On Thu, Oct 2, 2008 at 9:37 AM, Jesus Cea <[EMAIL PROTECTED]> wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Barry Warsaw wrote: >>>> IIUC, the critical bottleneck is tagging the tree, so the RM needs to >>>> make it far enough through the PEP to get to that point. Of course that >>>> does mean freezing the tree, and I don't think it's too difficult to do >>>> that. >>> >>> I always found strange the need to freeze the tree. When a svn tag is >>> created, the build process should use that tag to extract the files and >>> build the release, while the repository is being updated normally. >>> >>> In fact in a *.0 release, the tag should be a branch actually. >>> >>> Sure I'm missing something... >>> >>> - -- >>> Jesus Cea Avion _/_/ _/_/_/_/_/_/ >>> [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.8 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF >>> cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp >>> sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG >>> SNs5cVMhe7g= >>> =VRp9 >>> -END PGP SIGNATURE- >>> ___ >>> python-committers mailing list >>> python-committers@python.org >>> http://mail.python.org/mailman/listinfo/python-committers >>> >> ___ >> python-committers mailing list >> python-committers@python.org >> http://mail.python.org/mailman/listinfo/python-committers >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Cutting Python 2.6
That's why I wrote the welease.py script. Dunno if you've been using it. I wanted to make the release process as foolproof as possible so I wouldn't screw it up :-) On Thu, Oct 2, 2008 at 12:02 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Oct 1, 2008, at 9:47 PM, Anthony Baxter wrote: > >> Sure, but that's more fiddly. From experience, when you're cutting >> releases, making things as simple as possible is a good thing. > > Especially when a lot of the process is scripted. > > - -Barry > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Darwin) > > iQCVAwUBSOQry3EjvBPtnXfVAQJI7wP9HOtS7jMhOX4g47PZ4mNUs6VYywBEV7uo > LZo0EuqJHiWfOHjkmpAipxo2ApXhhqpvFgGNtDBx4lPnsjbJbsrg2TO2/F8fwkMA > O9oR3oQ5opUD5tONwE5q/1GHJPssw+UazqPP3262+K0UFS5IqwDlDu2msx3/H+sv > YaB6kAykvMA= > =Z8ir > -END PGP SIGNATURE- > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Cutting Python 2.6
On Thu, Oct 2, 2008 at 4:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> You're absolutely right and that sounds good. I will update the PEP >> accordingly. Martin, Ronald, Sean, what timezones are you in? I am >> US/Eastern. > > I'm in CET (Central European), that GMT+2 in DST, and GMT+1 otherwise. > > As for Sean: Sean and me had agreed that we won't do RPMs anymore for > 2.5.x. Maybe we need to reconsider now, but my view is that binary RPMs > typically fit a very specific OS release only (e.g. some version of > Redhat); all the other RPM-using distributions (SuSE etc) couldn't use > it. So compared to the value, the effort is too big. +1. Last time I looked (a fair while ago now) the number of downloads of the RPM packages wasn't that large. ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.0rc2 schedule
On Thu, Oct 2, 2008 at 4:47 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I propose that the release of 3.0rc2 is deferred until all release > blockers have been resolved (either by actually fixing them, or by > carefully considering that they shouldn't actually block the release). > > What else is the point of having the "release blocker" priority, if > they don't actually manage to block the release? +10. Absolutely. > Also, I would like to think that there shouldn't be any > non-documentation changes between the last release candidate, and > the final release(*). Otherwise, what's the point of calling it > a "release candidate" if it doesn't actually get released, later? > IOW, what's the difference to a beta release? > > (*) Consequently, there doesn't need to be much more time between > the release candidate and the final release except but a few days, > or, at most, a week. That's been the policy for the last few releases, as far as I can recall. ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.0rc2 schedule
IMHO if there's still big scary stuff out there, calling this a release candidate does us no good PR-wise, and does no good for our users. 3.0 is going to be scary enough for them as it is - cutting a release candidate that we either know is broken, or else has significant changes, is a very bad idea. On Fri, Oct 3, 2008 at 12:39 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Fred Drake wrote: >> On Oct 2, 2008, at 8:59 AM, Nick Coghlan wrote: >>> A big +1 from me for declaring it still in beta until all the 3.0 >>> release blockers are fixed. >> >> +1 from me as well. From what I've read about the pathname issues, I'm >> pretty worried about the usability of 3.0. > > If you don't make a habit of borking your own filesystems with dodgy > filenames, it runs fine. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- >http://www.boredomandlaziness.org > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Cutting Python 2.6
On Fri, Oct 3, 2008 at 7:06 AM, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 2, 2008 at 4:25 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> > wrote: >> >> > You always create a branch for the release (subversion doesn't make any >> > distinction between a tag and a branch anyhow, so you might as well just >> > make a branch). >> >> I don't think the tag should be edited (there are a few that were, and >> that's unfortunate already). For example, conversion to bzr will >> conclude it's a bazaar branch, not a tag. > > I agree, that's why I think we should make a branch. Tags should be treated > as immutable - it's merely an artifact of a limitation in the source control > system we use that you can't make real labels. > >> >> It's standard procedure to change the code after declaring it >> releasable; during the release process, the version numbers get adjusted >> throughout, and those changes get committed before the release tag is >> made. > > I guess my question is, is there a normal use case where the code needs to > be changed for a release after the 'tag' is made? If all the changes are > getting committed before the release tag is made, then what is the problem? It's happened a couple of times when I've made releases - the process I had was to automate it as much as possible, then take the generated tarball, unpack it freshly and run the full tests, and then check things like the README and all those other places. Making a release is still a pretty fiddly process, and things slip through. ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Python 3.0 branches ready
Don't be silly, you don't really think the PSU would go after someone is a release manag On Dec 4, 2008 4:56 AM, "Barry Warsaw" <[EMAIL PROTECTED]> wrote: On Dec 3, 2008, at 12:31 PM, Antoine Pitrou wrote: > Le mercredi 03 décembre 2008 à 12:27 -0500, Ba... I hope not, but there's a black van with the letters PSU written on the side sitting in front of my hou ___ python-committers mailing list [EMAIL PROTECTED] ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Why r69846 is not merged to "release26-maint"?
Speaking as a past release manager, the reason that things like that didn't get merged is because... drumroll... no-one merged them. It's another tree to checkout and patch. Personally, I was always of the belief that if someone wanted to fix docs (or comments, or other things like that) in a maintenance branch, more power to them. On Fri, Jul 3, 2009 at 12:43 AM, Benjamin Peterson wrote: > 2009/7/2 Jesus Cea : > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > I have found a few flaws in 2.6 documentation. I was going to correct > > them when I found they are already solved in trunk in r69846, done by > > mark.dickinson in february. > > > > Is there any reason for that commit not to be merged to 2.6 branch?. Am > > I missing anything?. > > People usually don't merge documentation changes because it's more > trouble than it's worth. You can merge that one, though. > > > > -- > Regards, > Benjamin > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Why r69846 is not merged to "release26-maint"?
The particulars of the revision control system don't matter as much as the discipline of teaching people to commit fixes. Right now, we have 2.6.x, 3.0.x and 3.1.x. On Fri, Jul 3, 2009 at 1:22 AM, Jeroen Ruigrok van der Werven < asmo...@in-nomine.org> wrote: > -On [20090702 17:15], Jesus Cea (j...@jcea.es) wrote: > >Ughhh. This is actually a good reason to migrate to mercurial, were > >merges are painless :-). > > For all I know Mercurial doesn't make the issue of resolving content merges > easier, so that would make your comment moot. > > -- > Jeroen Ruigrok van der Werven / asmodai > イェルーン ラウフロック ヴァン デル ウェルヴェン > http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B > When you do something, you should burn yourself completely, like a good > bonfire, leaving no trace of yourself... > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Why r69846 is not merged to "release26-maint"?
I think Barry should totally cut a completely pointless 3.0.2 release. We can call it the "homage to 1.6" release. Anthony On Fri, Jul 3, 2009 at 4:24 AM, Barry Warsaw wrote: > On Jul 2, 2009, at 1:56 PM, Brett Cannon wrote: > > If I remember correctly I believe we decided at the language summit that >> 3.0 >> is just dead now that 3.1 is out and we shouldn't even bother with another >> point release since 3.1 followed 3.0 so closely and didn't introduce any >> new >> syntax or tweak semantics. >> > > Right. There have been rumblings of wanting a 3.0.2, and I could do it if > the clamor were loud enough, but I still think we don't need one. > > -Barry > > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Data corruption issue (C IO library)
I have in the past done a microrelease without a release candidate. It didn't go well. On Fri, Aug 7, 2009 at 1:22 PM, Benjamin Peterson wrote: > Hi everyone, > I'm just getting back from the nice trip to the Olympic Peninsula. I > should be able to do a release sometime next week. In the meantime, > could someone post the patch to the 3.1 download site? (We should add > a note to the quick links section, too.) > > 2009/8/6 Georg Brandl : > > We can either make a release with only that patch applied, or a release > of > > the full 3.1-maint branch, but the latter would need alphas and betas. > > Why does that require doing alphas and betas? I believe the 2.5.x > releases only had a RC and the 3.0.1 and 2.6.x had no preview releases > before the final bugfix release. > > > -- > Regards, > Benjamin > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Data corruption issue (C IO library)
Its also about preventing the brown paper bag releases caused by stupid screwups. On Aug 7, 2009 8:08 PM, "Nick Coghlan" wrote: Georg Brandl wrote: > OK, maybe alphas and betas were a bit too skeptical; but there needs to be > *... As has been noted, release candidate -> maintenance release is the approach that has worked well in the past. Only including bug fixes means the alpha/beta stages aren't needed, but going through an RC makes sure the installers and the like are all in a happy state as well. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ python-committers mailing list python-committ...@pyt... ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
Often the NEWS entry ends up being rewritten from the commit message to be more user-focussed description of the change... On Sep 14, 2009 6:33 PM, "Georg Brandl" wrote: Brett Cannon schrieb: >> brainstorm: >> >> It'd be nicer if we could generate the file from another source, >> perhaps ke... We should just switch to Mercurial :) I've already hacked up a hg extension to automatically fill the commit message with the changes in a NEWS or CHANGELOG file. This works quite well -- you add the short but nice description to NEWS, do "hg commit", and the editor pops up where you can either accept the message consisting of only the changes in NEWS, or add some more stuff that's not interesting to users. cheers, 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-committers mailing list python-committ...@py... ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?
I strongly urge another release candidate. But then, I am not doing the work, so take that advice for what it is... On Oct 14, 2009 10:18 AM, "Barry Warsaw" wrote: On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: >> I always thought that the idea of a release ... No, but let's do one anyway! So, we can either make Sunday's release rc2 and do the final release one week later, or I can try to get an rc2 out in the next day or two, with a final release mid-next week. Thoughts? -Barry ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Googler Python committers
Yep. People tend to stop being so active when they join Google (including me) :-( There's a fair number of current or ex Python dev folks at Google. Guido, Jeremy H, Alex M, Neal N, Thomas W off the top of my head, I am certain there's a bunch more... On Oct 17, 2012 4:12 AM, "Gregory P. Smith" wrote: > > On Tue, Oct 16, 2012 at 7:44 AM, Chris Jerdonek > wrote: > >> On Tue, Oct 16, 2012 at 6:32 AM, Eli Bendersky wrote: >> > >> > I had the privilege of joining Google's Mountain View office yesterday, >> and >> > was wondering who else from the core development team works there, or in >> > Google in general (in addition to Guido, of course). >> >> Congrats, Eli! This may not be complete or accurate, but (and this >> tip can be useful to everybody), the list of committers here has a >> column that in some cases shows a company. Several people from Google >> are listed: >> >> >> http://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300 > > > That isn't up to date and users cannot edit their own information (at > least it tells _me_ I'm not authorized when I submit the edit form on my > own info) so I wouldn't trust that page. Yet another silly profile to > maintain in yet another location. sigh. > > There are many Google committers though not all are active. > > -gps > > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Googler Python committers
Fair enough - I did say "tend". :) On Wed, Oct 17, 2012 at 11:33 AM, Gregory P. Smith wrote: > > On Tue, Oct 16, 2012 at 5:06 PM, Anthony Baxter > wrote: >> >> Yep. People tend to stop being so active when they join Google (including >> me) :-( > > My activity increased. I would not make that statement. > > -gps ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Policy for committing to 2.7
Maybe time it so when we *would* have released a 2.8 (18 months or so after 2.7) is when it goes into critical/security fixes only? On Jun 22, 2013 11:50 PM, "Eli Bendersky" wrote: > > > > On Sat, Jun 22, 2013 at 12:35 PM, Barry Warsaw wrote: > >> On Jun 22, 2013, at 12:02 PM, Eli Bendersky wrote: >> >> >I may be missing something, but do we have a policy of what we're >> supposed >> >to commit to the 2.7 branch at this point? I was under the impression >> that >> >it's only bug fixes, documentation, and maybe tests. But it seems that >> >there are developers who see it otherwise. >> >> Strongly agree. One additional allowed category of changes are build >> system >> fixes, e.g. so that 2.7 can still be built on newer versions of operating >> systems it already supports. >> > > Yes, this makes sense too. > > In general there seems to be an agreement, so it would be great to > document in some place. Many years will pass before we have another > "special" release like Python 2.7, so it's worth spending an extra few > minutes to have this written down. PEP 404 seems to be a reasonable place - > any objections? Benjamin, what do you think? > > Eli > > > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Trunk is ready for 3.4.0a2 work
http://www.voodoochilli.net/artwork/illustration/chickens-of-war/ On Aug 4, 2013 4:34 PM, "Larry Hastings" wrote: > > > All the release engineering work for 3.4.0a1 has been merged. Cry havoc, > and let slip the checkins of war! > > > */arry* > > ___ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > > ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] More explicit Code of Conduct for the issue tracker & core mailing lists?
I approve of this. I wonder if we can't radically simplify it? Don't be awful. If someone says 'hey um that makes me uncomfortable' perhaps reconsider what you said. Perhaps say "oh oops, sorry". Don't be an awful person. Codes of conduct are awesome, but it depresses me that we need to write down rules of basic human decency. On 15 Jul 2015 11:38 pm, "Barry Warsaw" wrote: > On Jul 15, 2015, at 12:29 PM, Nick Coghlan wrote: > > >The FreeBSD community recently posted their Code of Conduct guidelines > >for technical discussions at > >https://www.freebsd.org/internal/code-of-conduct.html > > I wouldn't mind something shorter, perhaps a happy middle ground between > that > and the PSF CoC? In any case, +1 though... > > >Would folks mind if I drafted a CPython Code of Conduct inspired by > >their example, and proposed it for inclusion in the Developer's Guide? > > Why not put it in a low-numbered informational PEP? > > Cheers, > -Barry > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
