[python-committers] Re: list of core-devs, triagers, etc.

[Benjamin Peterson]

Does https://github.com/python/voters/ suffice?

On Sun, Feb 13, 2022, at 19:16, Ethan Furman wrote:
> Greetings!
>
> Is there a list somewhere of the core developers and triagers?
>
> I'm looking to prune the core-mentorship subscriber list as I'm 
> confident 90%+ are folks that wanted help learning 
> Python, not folks wanting help to develop Python itself.  Towards that 
> end I want to unsubscribe anyone who has not been 
> active in the last six months, excepting core-devs and triagers.
>
> Any and all help appreciated!
>
> --
> ~Ethan~
> ___
> 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/7O37WVGVU2V2FZMNIUU5OIFO344D5DO3/
> 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/6NVRZHYMIUR2HIZFKIAJGZ3LOWXPXWML/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Do I qualify for a x...@python.org email

[Benjamin Peterson]

For future reference, the policy is documented here: 
https://www.python.org/psf/records/board/policies/email/

On Sat, Oct 2, 2021, at 13:11, Joannah Nanjekye wrote:
> Thanks Mariatta
>
> On Sat, Oct 2, 2021 at 3:07 PM Mariatta  wrote:
>> Hi Joannah,
>> 
>> Yes you can request the email address by writing to postmas...@python.org
>> 
>> 
>> 
>> On Sat., Oct. 2, 2021, 10:02 a.m. Joannah Nanjekye, 
>>  wrote:
>>> Am migrating slowly away from using my Gmail address which I use for 
>>> CPython correspondence and development.
>>> 
>>> I plan to use my university email in the interim, when I graduate it will 
>>> be a different story, I may lose it.
>>> 
>>> So do I qualify for an x...@python.org email for purposes of CPython 
>>> development?
>>> 
>>> If so, who is responsible for coordinating this?
>>> 
>>> -- 
>>> **Best,
>>> Joannah Nanjekye
>>> *"You think you know when you learn, are more sure when you can write, even 
>>> more when you can teach, but certain when you can program." 
>>> Alan J. Perlis*
>>> ___
>>> 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/547AHP76RIVXSEBJLGWP64HL2LTFPYVL/
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
> -- 
> **Best,
> Joannah Nanjekye
> *"You think you know when you learn, are more sure when you can write, 
> even more when you can teach, but certain when you can program." 
> Alan J. Perlis*
> ___
> 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/O6KDE24MHNL26HJWZXNP6ZLOMGT2672U/
> 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/NOLNJLAXAGBE3FDZVJI2RMP4W3DJM3OO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Publish better than md5sums of Python builds?

[Benjamin Peterson]

On Wed, Mar 17, 2021, at 09:29, Victor Stinner wrote:
> On Tue, Mar 16, 2021 at 9:16 PM Gregory P. Smith  wrote:
> > The benefit of listing the sha256 for files is that it prevents this 
> > question coming up again and again because md5 is old and rightfully on the 
> > "never use" list for many people. Even if there are situations where it is 
> > fine as an effective improvement over a CRC.
> 
> Would it be possible to provide multiple hashes, like MD5 *and* SHA256
> (and maybe also SHA512)? Or is there a practical problem to list
> multiple hashes on a web page?

How about zero hashes?
___
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/NZBWDBM7VJVW66ZRIPDWYIAAYRVUNF3U/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Benjamin Peterson]

On Wed, Sep 11, 2019, at 00:32, Steven D'Aprano wrote:
> On Tue, Sep 10, 2019 at 09:49:00AM +0100, Benjamin Peterson wrote:
> > 
> > 
> > On Tue, Sep 10, 2019, at 06:54, Raymond Hettinger wrote:
> > > Another essential bit of tooling for the migration:
> > > 
> > > * Before filing a bug report or feature request, we ask people to 
> > > search to see if there is already an issue in progress or a resolved 
> > > issue on the topic.   We need to make sure that on GitHub issues, 
> > > people can still search our voluminous history of already evaluated and 
> > > decided feature requests.
> > 
> > I think is something that GitHub already does well compared to 
> > Roundup. GitHub can suggest related issues as you type into the "new 
> > issue" box. https://github.blog/changelog/2018-11-05-related-issues/
> 
> That's still in beta, and you have to opt-in to use it.
> 
> I just tried it, it doesn't work for me. Even if I type the exact same 
> issue title as one already existing, it makes no suggestions. (This 
> doesn't surprise me, hardly anything on github works for me, nor will 
> they until I can afford a new computer.)
> 
> In any case, it doesn't answer Raymond's request. Even if the Related 
> Issues feature works for you, it doesn't help you track down an 
> existing issue if you're not trying to create a new issue. E.g. you 
> might be searching for an issue you remember seeing but don't know the 
> URL to, or you might be researching something for a PEP and want to find 
> relevant issues. Or you might just be dissatisfied with Github's 
> suggestion algorithm, and want to try with different keywords.
> 
> Having said that, the "Filters" feature does seem to do the trick. I 
> just tried it on a project I picked at random:
> 
> https://github.com/sorccu/cufon/issues?q=is%3Aissue+is%3Aopen
> 
> and it seems quite good. It is quite prominent, and on a couple of quick 
> tests it seems to do the job well. Although using search options 
> ("is:open") in the search box rather than GUI controls will, I think, 
> increase the barrier to entry for beginners.

In other words, vanilla GitHub issue search does address Raymond's request?

> 
> Can Github search the past history on b.p.o as well?

That seems unlikely to happen.
___
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/KA7EO6JS2RRDMOUQ5DNQA7JIHHKNR6ZZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Make AppVeyor CI non-mandatory during the CPython sprint?

[Benjamin Peterson]

On Tue, Sep 10, 2019, at 08:54, Victor Stinner wrote:
> Le lun. 9 sept. 2019 à 18:46, Benjamin Peterson  a écrit 
> :
> > No one could think of a reason not to replace AppVeyor with Azure, so I've 
> > gone ahead and done that on all those branches.
> 
> Here is a reason to not replace AppVEyor with Azure:
> https://bugs.python.org/issue37245
> 
> The macOS job of Azure fails randomly, I reported the bug in June, no
> one managed to fix it yet (Steve just made progress on it, thanks!),
> and the whole Azure job is marked as "failed" if macOS fails. It seems
> like it's yet another multiprocessing bug.
> 
> Would it be possible to change the macOS job of Azure to mark it as optional?

Someone familiar with pipelines would have to answer that.
___
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/ZX4V2Y6AUTEJI5CDX5WKB4USK3EJJFWW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Benjamin Peterson]

On Tue, Sep 10, 2019, at 06:54, Raymond Hettinger wrote:
> Another essential bit of tooling for the migration:
> 
> * Before filing a bug report or feature request, we ask people to 
> search to see if there is already an issue in progress or a resolved 
> issue on the topic.   We need to make sure that on GitHub issues, 
> people can still search our voluminous history of already evaluated and 
> decided feature requests.

I think is something that GitHub already does well compared to Roundup. GitHub 
can suggest related issues as you type into the "new issue" box. 
https://github.blog/changelog/2018-11-05-related-issues/
___
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/HUJMQNJ6FW4DURNRGIXRKQSJ5HSFG5YW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Make AppVeyor CI non-mandatory during the CPython sprint?

[Benjamin Peterson]

On Mon, Sep 9, 2019, at 20:15, Terry Reedy wrote:
> On 9/9/2019 12:46 PM, Benjamin Peterson wrote:
> > 
> > 
> > On Mon, Sep 9, 2019, at 16:50, Victor Stinner wrote:
> >> Hi,
> >>
> >> I see a high activity on pull requests on the CPython project, likely
> >> because of the CPython sprint. Sadly, the AppVeyor is still slow and
> >> still has only 2 jobs in parallel.
> 
> A couple of years ago, I suggested that we treat testing time as a 
> limited resource and not run unneeded tests.  I still think this a good 
> idea.  The problem will only get worse in the future.
> 
> For instance, a PR properly labelled 'documentation' does not need code 
> checks.  I don't believe that a PR with only such changes needs any 
> check other than to verify that changes in .py files are limited to 
> docstrings and comments.  Similarly for C comments.

We already prune the full test suite from documentation-only changes. (See 
"before_install" in .travis.yml.)

Figuring out how to detect whether a change is just comments is probably not 
worth it; there aren't really many PRs of that nature.

> 
> > Yeah, there has been quite some crankiness about this at the sprint. :)
> > 
> >>
> >> Would it be possible to make the AppVeyor job non-mandatory to allow
> >> to merge a PR faster? If it's configurable per branch, it would be
> >> nice to do this change for 2.7, 3.7, 3.8 and master branches.
> > 
> > No one could think of a reason not to replace AppVeyor with Azure, so I've 
> > gone ahead and done that on all those branches.
> 
> Azure sometimes has false positive failures on the mac test where it 
> times out after an hour because one of the tests hangs.  This has 
> happened to me twice in the last month.  Can you make that not a 
> requirement?

It would be best if we could figure out how to fix that problem.
___
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/UTGBUSTERB72X2V6VA7LMD3DYY33PRPJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Make AppVeyor CI non-mandatory during the CPython sprint?

[Benjamin Peterson]

On Mon, Sep 9, 2019, at 16:50, Victor Stinner wrote:
> Hi,
> 
> I see a high activity on pull requests on the CPython project, likely
> because of the CPython sprint. Sadly, the AppVeyor is still slow and
> still has only 2 jobs in parallel.

Yeah, there has been quite some crankiness about this at the sprint. :)

> 
> Would it be possible to make the AppVeyor job non-mandatory to allow
> to merge a PR faster? If it's configurable per branch, it would be
> nice to do this change for 2.7, 3.7, 3.8 and master branches.

No one could think of a reason not to replace AppVeyor with Azure, so I've gone 
ahead and done that on all those branches.

> 
> I will keep an eye on buildbots to see if something bad happens :-)

What a hero!
___
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/AHJ7ANXEKRT4IMI3YVSJWLPAL5JJK7KA/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] [Python-Dev] Farewell, Python 3.4

[Benjamin Peterson]

Thank you for your service!

On Wed, May 8, 2019, at 08:37, Larry Hastings wrote:
> 
> 
> It's with a note of sadness that I announce the final retirement of 
> Python 3.4. The final release was back in March, but I didn't get 
> around to actually closing and deleting the 3.4 branch until this 
> morning.
> 
> Python 3.4 introduced many features we all enjoy in modern Python--the 
> asyncio, ensurepip, and enum packages, just to name three. It's a 
> release I hope we all remember fondly.
> 
> My eternal thanks to all the members of the release team that worked on 
> Python 3.4:
> 
> > Georg Brandl
> 
> > Julien Palard
> 
> > Martin von Löwis
> 
> > Ned Deily
> 
> > Steve Dower
> 
> > Terry Reedy
> 
> > and all the engineers of the Python infrastructure team.
> 
> Special thanks to Benjamin Peterson and Ned Deily, who frequently 
> scurried around behind the scenes cleaning up the messes I cluelessly 
> left in my wake.
> 
> Having closed 3.4, I am now retired as Python 3.4 Release Manager. I 
> regret to inform all of you that you're still stuck with me as Python 
> 3.5 Release Manager until sometime next year.
> 
> 
> 
> My very best wishes,
> 
> 
> 
> */arry*
> 
> ___
> Python-Dev mailing list
> python-...@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
>
___
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/

Re: [python-committers] discuss.python.org participation

[Benjamin Peterson]

On Fri, Oct 12, 2018, at 11:55, Brett Cannon wrote:
> On Thu, 11 Oct 2018 at 01:30, Antoine Pitrou  wrote:
> 
> >
> > What concerns me is that there are several long-time and/or prominent
> > developers who are not even registered (*) on discuss.python.org.  For
> > example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan
> > Krah, Terry Reedy.
> >
> 
> I believe Larry is currently busy so he might simply have not taken the
> time (and will be occupied into I believe November).
> 
> I will also note that Benjamin, Larry, and Raymond can be a bit quiet at
> times and so they may not have signed up yet because they have not had
> anything to say to compel them to create accounts (Stefan has already
> stated he doesn't like this idea so I'm assuming that might be why he has
> not signed up yet).

Brett is exactly right about me. I'm following along on Discourse and this 
mailing list when I have the time. I plan to read the governance PEPs and vote 
when the time comes. But, I don't have anything useful to say.

At the sprint, I verbally supported Łukasz's plans to try out Discourse. 
Discourse isn't perfect and may feel uncomfortable, but we're also losing 
potential contributors because they find mailing lists uncomfortable.
___
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/

Re: [python-committers] Recent buildbot.python.org changes

[Benjamin Peterson]

On Fri, Sep 14, 2018, at 14:02, Zachary Ware wrote:
> Hi all,
> 
> Most of my effort this week has gone into improving the state of
> buildbot.python.org, which has largely gone into improving Buildbot
> itself.  Here are the relevant highlights:
> 
> - Anyone can now log into buildbot.python.org via GitHub by clicking
> the 'Anonymous' dropdown in the upper right corner, then 'Login with
> GitHub'.  The first time, GitHub will ask you for approval;
> subsequently you'll just be logged right in.
> 
> - Stopping builds and triggering rebuilds is now restricted to members
> of the `python-core` team and the "owner" of a build.  I've not had
> opportunity to test whether the author of a commit actually qualifies
> as the "owner" or if only the committer does, but if anyone runs into
> trouble with it please open an issue on the buildmaster-config repo.
> 
> - Disabling/enabling schedulers is now restricted to members of the
> `python-release-managers` team.  We had an issue some months ago where
> someone had apparently disabled the scheduler for one of our branches,
> resulting in no builds on that branch for several days before we
> noticed.  That shouldn't happen again!
> 
> - Buildbot now reports results from our stable builders on each tested
> commit.  For now, we're still only running tests post-merge, so you
> won't see new status checks on PRs, but you can find results on
> https://github.com/python/cpython/commits/
> 
> Let me know if any of these changes negatively impact you, or if you
> have suggestions for further improvement.

Thanks for all your work.
___
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/

Re: [python-committers] Visual Studio Team Services checks on pullrequests

[Benjamin Peterson]

On Wed, May 16, 2018, at 15:27, Steve Dower wrote:
> Thanks Microsoft for the 20 concurrent builds on Windows, macOS and Linux :)

That is quite generous! Will it be ongoing?
___
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/

Re: [python-committers] Can we delete https://hg.python.org/coding/cpython/?

[Benjamin Peterson]

Killed.

On Mon, Dec 19, 2016, at 14:23, Brett Cannon wrote:
> It's erroneously labeled as the "official python repo" and created by
> some
> stranger.
> ___
> 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/

Re: [python-committers] autoconf 2.70

[Benjamin Peterson]

The correct way to solve this is probably to stop checking in the
generated configure and generate it with a "blessed" autoconf version in
the release tarballs.

On Sun, Sep 11, 2016, at 13:17, Xavier de Gaye wrote:
> On 07/22/2016 06:41 PM, Brett Cannon wrote:
>  >
>  >
>  > On Fri, 22 Jul 2016 at 06:02 Xavier de Gaye  > wrote:
>  >
>  > It seems that the configure file on the default branch has been 
> generated with
>  > autoconf 2.70. Autoconf 2.70 has not yet been released [1].  The 
> differences
>  > between the generated configure files with 2.69 and 2.70 are a few 
> lines [3]
>  > added by 2.70 with 'runstatedir' in them.  The last old discussion on 
> the
>  > usage of different autoconf versions [2] does not really answer the 
> following
>  > question:
>  >
>  > I am using 2.69, should a commit that changes configure.ac 
>  respects the
>  > existing 'runstatedir' lines added by a previous commit or uses 
> directly the
>  > configure file generated by 2.69 ?
>  >
>  >
>  > If autoconf 2.70 is not released yet then it's fine to regenerate 
> configure w/ 2.69.
>  >
>  > -Brett
> 
> 
> Changeset 816ae3abd928 regenerated the configure script with
> 'runstatedir'
> again. AFAIK Autoconf 2.70 has still not yet been released. Please let us
> stick
> with 2.69.
> 
> Xavier
> ___
> 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/

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[Benjamin Peterson]

Brett, thank you very much for putting your (vacation!) time into this.

On Fri, Jan 1, 2016, at 11:24, Brett Cannon wrote:
> If you want to read the reasons I chose GitHub over GitLab, see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
> .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.
> 
> Happy 2016 everyone, and here is to hoping we will have an easier
> developer
> workflow by the end of this year!
> ___
> 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

Re: [python-committers] Committer missing :)

[Benjamin Peterson]

Indeed, if you have no keys around, the (automatically generated)
committers.txt file will not list you.


On Sun, Dec 6, 2015, at 17:05, Jesus Cea wrote:
> I was trying to push a patch but it seems I am not a committer anymore.
> My name vanished of  and the
> tracker.
> 
> I guess I had a DSA key in hg.python.org and those are not valid
> anymore, but looks like I am not a documented committer anymore in order
> to send a new 2048 bits RSA key.
> 
> I don't know if this is a mistake or a decision. Just let me know.
> 
> -- 
> Jesús Cea Avión _/_/  _/_/_/_/_/_/
> j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
> Twitter: @jcea_/_/_/_/  _/_/_/_/_/
> jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> 
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PSA: replace your DSA keys for SSH

[Benjamin Peterson]

On Wed, Oct 7, 2015, at 19:38, Tim Peters wrote:
> [Benjamin Peterson ]
> > As a followup to this, I have now removed all DSA keys. People who only
> > had DSA keys will need to submit new keys to hgaccounts@.
> 
> That apparently was addressed to me - cool ;-)
> 
> Just noting that the Windows section of the devguide:
> 
> https://docs.python.org/devguide/faq.html
> 
> should probably be changed to say something other than the current:
> 
> Use PuTTYgen to generate your public key. Choose the
> “SSH2 DSA” radio button,
> 
> That may be a clue as to why Windows devs generated DSA keys to begin
> with ;-)
> 
> PuTTYgen also has a "SSH-2 RSA" radio button, and #-of-bits box into
> which 4096 can be typed.

Thank you. I updated the page with exactly you suggest yesterday. The
automatic doc building process unfortunately hadn't run yet.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PSA: replace your DSA keys for SSH

[Benjamin Peterson]

On Wed, Oct 7, 2015, at 18:52, Raymond Hettinger wrote:
> 
> > On Oct 6, 2015, at 11:43 PM, Benjamin Peterson  wrote:
> > 
> > As a followup to this, I have now removed all DSA keys. People who only
> > had DSA keys will need to submit new keys to hgaccounts@.
> 
> That was rather sudden and harsh.
> Effectively, you just revoked my commit rights.

I'm sorry. Most keys which I removed where for long–dormant comitters.
Likely, no amount of waiting would have resulted in these keys being
replaced. The sudden removal of DSA keys would have happened sooner or
later anyway when we upgraded to a newer version of openssh.

> 
> I'll wrestle with the new key submission as soon as I can.
> It would have been better though to have had all the devs
> upgraded *before* deleting their keys.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PSA: replace your DSA keys for SSH

[Benjamin Peterson]

As a followup to this, I have now removed all DSA keys. People who only
had DSA keys will need to submit new keys to hgaccounts@.

On Thu, Aug 27, 2015, at 13:36, Georg Brandl wrote:
> Hi all,
> 
> newer OpenSSH versions (7.0+) default to not allowing ssh-dss keys for
> public key authentication.  If you experience "permission denied" errors,
> this (currently) comes from the client side only and hg.python.org will
> accept these keys if you enable them using the PubkeyAcceptedKeyTypes
> option in your SSH config file.
> 
> Of course ssh-dss is being phased out for a reason; we'd like to invite
> everybody who has only DSA keys submitted for hg.python.org access to
> send an RSA (min. 1024 bits) or ED25519 key to hgaccou...@python.org.
> 
> cheers,
> Georg
> 
> ___
> 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

Re: [python-committers] SSH problems attempting to access hg.python.org

[Benjamin Peterson]

What does `ssh-add -L` give? ssh basically throws keys at the server
until the server accepts it. The server has a limit of two attempts, so
if have more than two keys in your agent, problems result.

On Thu, Oct 1, 2015, at 01:57, Nick Coghlan wrote:
> Hi folks,
> 
> After getting some publickey errors from hg.python.org earlier, I'm
> now consistently getting "Too many authentication failures for hg".
> 
> I've checked my SSH keys, and they're validating against other
> services OK, so this appears to be a problem with hg.python.org
> specifically.
> 
> Could someone with the appropriate admin access take a look at the
> server and see what might be going on?
> 
> Regards,
> Nick.
> 
> P.S. Relevant public key fingerprint (in both MD5 and SHA256 format):
> 
> 2048 MD5:07:7b:9c:2f:f1:e4:bb:f7:a2:2a:c9:f1:2e:6d:f1:ec
> ncoghlan@llamedos (RSA)
> 2048 SHA256:kz2qX96utlWroXvMf75x2WFiL0o2SEeHnX7eJStd3wc ncoghlan@llamedos
> (RSA)
> 
> -- 
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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

Re: [python-committers] PSA: replace your DSA keys for SSH

[Benjamin Peterson]

On Thu, Aug 27, 2015, at 16:36, Donald Stufft wrote:
> On August 27, 2015 at 4:37:21 PM, Georg Brandl (g.bra...@gmx.net) wrote:
> > Hi all,
> >  
> > newer OpenSSH versions (7.0+) default to not allowing ssh-dss keys for
> > public key authentication. If you experience "permission denied" errors,
> > this (currently) comes from the client side only and hg.python.org will
> > accept these keys if you enable them using the PubkeyAcceptedKeyTypes
> > option in your SSH config file.
> >  
> > Of course ssh-dss is being phased out for a reason; we'd like to invite
> > everybody who has only DSA keys submitted for hg.python.org access to
> > send an RSA (min. 1024 bits) or ED25519 key to hgaccou...@python.org.
> >  
> >
> 
> Can we bump up the minimum on RSA keys? 1024 isn’t really enough anymore,
> ideally they’d be at least 4096 but 2048 is also OK.

Even better: send a ed25519 key as documented in the devguide.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Weak SSH keys

[Benjamin Peterson]

On Wed, Jun 3, 2015, at 08:31, Antoine Pitrou wrote:
> 
> 
> Le 03/06/2015 15:27, Benjamin Peterson a écrit :
> > 
> > 
> > On Wed, Jun 3, 2015, at 08:21, Antoine Pitrou wrote:
> >>
> >> Le 02/06/2015 18:42, Benjamin Peterson a écrit :
> >>>
> >>>
> >>> On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
> >>>> Le 02/06/2015 18:28, Benjamin Peterson a écrit :
> >>>>>
> >>>>> Also, everyone should use ed25519 keys now. :)
> >>>>
> >>>> Depends if the servers you connect to have all been migrated to a recent
> >>>> enough OpenSSH.
> >>>
> >>> SSH can use your older keys if you don't delete them.
> >>
> >> Is there a way of debugging which key is actually used? "ssh -v" isn't
> >> very useful.
> > 
> > Really? I see output from ssh -v like this:
> > 
> > debug1: Offering ED25519 public key: /home/benjamin/.ssh/id_ed25519
> > debug1: Authentications that can continue: publickey
> > debug1: Offering RSA public key: /home/benjamin/.ssh/id_rsa
> > debug1: Authentications that can continue: publickey
> > debug1: Offering DSA public key: /home/benjamin/.ssh/id_dsa
> > debug1: Server accepts key: pkalg ssh-dss blen 435
> 
> Yes, but why does it try keys in that order? And why is a key accepted
> or not?

That's just how the SSH auth protocol works. The client offers keys
until the server finds one acceptable. I'm not sure how the order is
determined; it's probably arbitrary for OpenSSH.

See https://tools.ietf.org/html/rfc4252
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Weak SSH keys

[Benjamin Peterson]

On Wed, Jun 3, 2015, at 08:21, Antoine Pitrou wrote:
> 
> Le 02/06/2015 18:42, Benjamin Peterson a écrit :
> > 
> > 
> > On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
> >> Le 02/06/2015 18:28, Benjamin Peterson a écrit :
> >>>
> >>> Also, everyone should use ed25519 keys now. :)
> >>
> >> Depends if the servers you connect to have all been migrated to a recent
> >> enough OpenSSH.
> > 
> > SSH can use your older keys if you don't delete them.
> 
> Is there a way of debugging which key is actually used? "ssh -v" isn't
> very useful.

Really? I see output from ssh -v like this:

debug1: Offering ED25519 public key: /home/benjamin/.ssh/id_ed25519
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /home/benjamin/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering DSA public key: /home/benjamin/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 435
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Weak SSH keys

[Benjamin Peterson]

On Tue, Jun 2, 2015, at 12:35, Skip Montanaro wrote:
> On Tue, Jun 2, 2015 at 11:28 AM, Benjamin Peterson 
> wrote:
> > Also, everyone should use ed25519 keys now. :)
> 
> For people like myself who are behind the curve, can someone point me
> to a primer on generating new, more secure SSH keys?

You just have to pass the right option to ssh-keygen

https://docs.python.org/devguide/faq.html#how-do-i-generate-an-ssh-2-public-key
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Weak SSH keys

[Benjamin Peterson]

On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
> Le 02/06/2015 18:28, Benjamin Peterson a écrit :
> > 
> > Also, everyone should use ed25519 keys now. :)
> 
> Depends if the servers you connect to have all been migrated to a recent
> enough OpenSSH.

SSH can use your older keys if you don't delete them.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Weak SSH keys

[Benjamin Peterson]

On Tue, Jun 2, 2015, at 11:19, A.M. Kuchling wrote:
> Someone ran an experiment looking at the SSH keys used on GitHub
> (public keys are accessible through the API):
> 
> https://blog.benjojo.co.uk/post/auditing-github-users-keys
> 
> Excerpt:
> 
>   I remembered back to the May 2008 Debian OpenSSH bug, where
>   the randomness source was compromised to the point where the
>   system could only generate one of 32k keys in a set.
> 
>   I used g0tmi1k’s set of keys to compare against what I had in
>   my database, and found a very large amount of users who are
>   still using vulnerable keys, and even worse, have commit
>   access to some really large and wide projects including:
> 
>   ...
>   Crypto libraries to Python
>   Django
>   Python’s core
>   ...
> 
> CPython is not officially on github, so committing evil stuff to the
> github mirror may not matter very much, but these users may have the
> same key configured for hg.python.org.  Should we check everyone's SSH
> keys?

I believe Martin checked everyone's keys when that vulnerability was
announced. He certainly emailed me anyway.

Not that it wouldn't hurt to do again.

Also, everyone should use ed25519 keys now. :)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Do people prefer pushing feature repos or one massive patch?

[Benjamin Peterson]

On Wed, Apr 1, 2015, at 12:09, Brett Cannon wrote:
> The implementation for PEP 488 is basically done (sans Windows installer
> stuff). I did the work in a features repo at
> https://hg.python.org/features/pep-488/ . Once I have addressed reviewer
> comments at http://bugs.python.org/issue23731 , would people prefer I
> simply push the features repo to hg.python.org/cpython and have the more
> granular history but have various "merge default" commits, or would
> people
> rather I do one massive commit?

I tend to prefer the one massive commit especially if there's a lot of
"in progress" commits in the branch. It makes for cleaner and
more-transactional history.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] commit 93025:1c2c44313408 removed (at least) 2.7.9 NEWS entries

[Benjamin Peterson]

On Fri, Oct 17, 2014, at 10:55, Matthias Klose wrote:
> The commit 93025:1c2c44313408 removed almost all NEWS entries which were
> added
> after the 2.7.8 release.  I didn't check for other files, but maybe
> somebody
> more familiar with this commit/merge should have a look.

I've just pushed a commit fixing up NEWS.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Mark Lawrence

[Benjamin Peterson]

On Sun, Oct 5, 2014, at 14:42, Serhiy Storchaka wrote:
> On 05.10.14 21:15, Benjamin Peterson wrote:
> > "BreamoreBoy" is back on tracker touching hundreds of issues without
> > adding any new information. This is certainly not the first time. Can we
> > ban him?
> 
> I think it would be enough just to say him stop. He is not malicious.

I did. http://bugs.python.org/issue18372#msg228613

> 
> Actually there was few cases when his reminders was helpful.

That's true, though, I'm not sure noise is worth the few issues that are
closed.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Mark Lawrence

[Benjamin Peterson]

"BreamoreBoy" is back on tracker touching hundreds of issues without
adding any new information. This is certainly not the first time. Can we
ban him?
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit rights for Robert Collins

[Benjamin Peterson]

hgaccou...@python.org

On Sat, Oct 4, 2014, at 01:39, Michael Foord wrote:
> 
> On 24 Sep 2014, at 00:01, R. David Murray  wrote:
> 
> > On Mon, 22 Sep 2014 10:51:27 +0100, Michael Foord 
> >  wrote:
> >> Robert Collins is volunteering to help with maintenance and improvement 
> >> of unittest. He's probably known to many of you, but Robert is the 
> >> creator of subunit, testtools and many Python libraries particularly in 
> >> the area of testing.
> >> 
> >> I'd like Robert to have commit rights for this purpose. He's already 
> >> submitted quite a few fixes and patches. Most recently issue 16662.
> >> 
> >> http://bugs.python.org/issue16662
> >> 
> >> Robert is an experienced and accomplished Python developer, so won't 
> >> need much mentoring beyond learning our development processes (which 
> >> branches to merge to, when a bug fix can be backported etc). In as much 
> >> as he needs any mentoring I'm more than happy to work with Robert.
> > 
> > +1
> 
> It looks like there is general agreement that Robert should be given
> commit rights. I forget, who should he send his ssh keys to?
> 
> Thanks,
> 
> Michael
> 
> > 
> > --David
> 
> 
> --
> http://www.voidspace.org.uk/
> 
> 
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing 
> http://www.sqlite.org/different.html
> 
> 
> 
> 
> 
> ___
> 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

Re: [python-committers] [Python-Dev] new hg.python.org server

[Benjamin Peterson]

On Fri, Sep 12, 2014, at 21:52, Shorya Raj wrote:
> Just wondering - are there any sys-adminy sort of tasks that could be
> completed? I mean, I have some (note, some) experience doing this, and I
> wouldn't mind helping out (I inquired in the buildbot thread as well, but
> there wasn't much of a response).

Well, hg.python.org is basically done now. The main thing now is
understanding how other services (planet.python.org, bugs.python.org)
are setup and moving them to config management.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] new hg.python.org server

[Benjamin Peterson]

I just switched hg.python.org from a OSUOSL VM to a Rackspace VM. The
new VM is a bit beefier and has what I think is better network
connectivity, so hopefully that will improving the speed of repository
operations. We also now support HTTPS for repository browsing and
cloning, so update all your links to https://hg.python.org! IPv6 support
has also returned for those who like that sort of thing.

Note the host keys changed, so you'll probably have to futz with
known_hosts to quiet ssh down. I apologize, but I noticed that that the
current RSA host key is 1024 bits, so I decided to upgrade it to 2048
during the transition.

Thanks to Donald Stufft for helping me set this up.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Contact info for possible workflow tool security issue

[Benjamin Peterson]

On Thu, Jun 19, 2014, at 18:23, Antoine Pitrou wrote:
> 
> 
> Le 19/06/2014 21:13, Nick Coghlan a écrit :
> > A colleague spotted a possible security issue with one of the CPython
> > workflow tools (specifically with the configuration of our
> > installation, rather than with the upstream project), and would like
> > to know where to report it securely.
> >
> > Currently the developer guide covers CPython itself
> > (secur...@python.org), and infrastruct...@python.org is the likely
> > place for the main PSF infrastructure, but it isn't clear where such
> > problems with the CPython worfklow tools should be reported.
> 
> I think security@ is fine.
> infrastructure@ is not, since anyone can read it.

There's also infrastructure-st...@python.org, which is private, but they
don't own much of the CPython developer infra. If it's the tracker, for
example, you're better off emailing Martin/bitdancer/Ezio privately.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] default hg.python.org/cpython is now 3.5

[Benjamin Peterson]

On Mon, Mar 17, 2014, at 7:10, Brett Cannon wrote:
> On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner
> wrote:
> 
> > Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
> > accept security fixes, right?
> >
> 
> Typically we do one last release before shutting the last bugfix branch
> down, but that's Georg's call since 3.3.5 was released so recently.

Given that, I propose 3.3 goes into security fix mode immediately.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python Language Summit: please rsvp

[Benjamin Peterson]

I'll have to turn you down. Thanks, though.

On Thu, Feb 20, 2014, at 01:06 PM, Michael Foord wrote:
> Hey all,
> 
> The Python Language Summit is on Wednesday 9th April, prior to PyCon in
> Montreal. The summit will be from 10am to approximately 4pm. If you want
> to attend you *must* let me know prior to March 15th, as only registered
> attendees will have food provided for them.
> 
> Lunch will be served in room 710 at the Palais at 12:20pm. 
> 
> All the best,
> 
> Michael Foord
> 
> --
> http://www.voidspace.org.uk/
> 
> 
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing 
> http://www.sqlite.org/different.html
> 
> 
> 
> 
> 
> ___
> 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

Re: [python-committers] Commit access for Yury Selivanov?

[Benjamin Peterson]

On Wed, Jan 22, 2014, at 07:01 PM, Nick Coghlan wrote:
> On 20 January 2014 14:39, Nick Coghlan  wrote:
> >
> > On 20 Jan 2014 08:06, "Victor Stinner"  wrote:
> >>
> >> Is it enough to know the python process and how to write good patches? I
> >> don't see why Yury would become but not Vajrasky Kok.
> >
> > In this case, it's Yury's specific contributions to an orphan module and
> > being a co-author of an accepted PEP related to that module that motivate my
> > suggestion, rather than general bug fixing (which I agree would typically
> > involve a wider range of contributions).
> >
> > I see it as similar to the way we grant commit access to authors of "add a
> > module to the standard library" PEPs as a matter of course so they can
> > continue maintaining it.
> 
> Ping?
> 
> Yury's someone I run *my* inspect module changes by, so it would
> definitely make my life easier if I could +1 his patches and he could
> take care of committing and pushing them himself.

I don't see anyone complaining too loudly, so have him send his key to
hgaccou...@python.org.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Updated schedule for Python 3.4

[Benjamin Peterson]

On Thu, Jan 16, 2014, at 06:03 PM, Kristján Valur Jónsson wrote:
> I never got the impression that this was a matter of funding, Nick.
> And while I completely understand that core developers enjoy working in 3
> much more, it was decided to not accept any improvements for a +2.7
> version even from those that would do so voluntarily.  This could have be
> done without making any commitment to release a 2.8 at any point.
> This is why I drew the comparison.  There are barriers put in place to
> try to achieve a social engineering result.

It's not a matter of simply accepting any improvements for 2.7 even from
volunteers. If 2.8 happened, among other things people would have to
- make releases (building installers, etc)
- review new features
- triage bugs
- fix bugs in new features
- maintain yet another branch

It would surely add overhead for everyone.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.3.4 planning

[Benjamin Peterson]

On Thu, Jan 16, 2014, at 06:30 AM, Georg Brandl wrote:
> Hi all,
> 
> I'm planning to release 3.3.4 candidate 1 together with 3.4 beta 3, i.e.
> on
> the 26th -- and then 3.3.4 final two weeks later if nothing bad comes up.
> 
> As always, there will be one more full 3.3 release after 3.4 final,
> probably
> in the May-June timeframe.

Also, for those curious, this is when the 3.1 line will come to a
screeching halt.

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

[Benjamin Peterson]

On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
> On 8 Jan 2014 08:44, "Eric V. Smith"  wrote:
> >
> > On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
> > > A PyPI module is not so great because you'll have to change every
> > > formatting operation to use a function from a module rather than the %
> > > operator or the format method.
> >
> > I think this is the crux of the issue. Are we trying to say "porting
> > your existing code will be easier", or "change your existing code to
> > this new library, and we'll provide the library on 2.x and 3.y" (for
> > some values of x and y).
> >
> > I think the former is the right way to go, but I also think if we do
> > that we should shoot for 3.4, and this would necessitate a delay in 3.4.
> > Providing this feature for 3.5 might be too late for the target audience
> > of code porters.
> 
> I'm saying hacking in a complex change in a few weeks when there isn't
> consensus even on the basics of the design just because a few moderately
> high profile developers failed to understand what "5 years to be the
> default choice for new projects" meant would be the height of
> irresponsibility.

It's not design from scratch, since it should be fairly close to the 2.x
string formatting mini-languages.

> 
> The 5 year goal was for the Python 3 ecosystem to be a sufficiently
> functionally complete alternative to Python 2 for it to be recommended by
> default for every use case where Python 2 wasn't already being used.
> 
> Addressing the key remaining barriers to migration for existing Python 2
> users would be an excellent objective to attain before we end upstream
> support for Python 2.7, but it's one that would be better addressed by a
> slightly shorter dev cycle than normal for 3.5 than it would be by
> falling
> into the "just one more feature" trap for Python 3.4.

I think a shorter cycle for 3.5 is fine, too.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

[Benjamin Peterson]

On Tue, Jan 7, 2014, at 04:29 PM, Nick Coghlan wrote:
> On 8 Jan 2014 07:11, "A.M. Kuchling"  wrote:
> >
> > On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote:
> > > Just to be clear, this is exactly what I mean. I'm not saying AC is not
> > > worth it; I'm questioning the timing.
> >
> > Agreed; let's try to avoid far-ranging sets of changes so late in the
> > beta cycle.
> >
> > If we want to send 3.4 back to alpha and implement some form of
> > string-formatting changes and Argument Clinic, that would be fine,
> > though it might mean Ubuntu and other Linux distros might have to ship
> > with 3.3 again because 3.4 wasn't done in time.
> 
> The bytes formatting change is right out. It likely requires the use of
> the
> 3.3 or 2.7 bytestring formatting code as the basis and should be feasible
> to implement and publish as a function in a cross-version PyPI library
> before locking in the syntax and semantics for Python 3.5, so I see zero
> justification for delaying Python 3.4 on that basis. It's relevant to the
> question of encouraging migrations from Python 2 (as current Python
> developers are used to having a feature like that available), but is not
> especially significant in terms of encouraging *new* development in
> Python
> 3 (since it's a relatively obscure use case with multiple alternative
> approaches available).

A PyPI module is not so great because you'll have to change every
formatting operation to use a function from a module rather than the %
operator or the format method.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] svn.python.org SSL cert is expired

[Benjamin Peterson]

I was going to get another CACert certificate for svn.python.org, but
I forgot you need to verify the domain (by getting email at root@)
before CACert will issue a cert for it. I suppose I could generate
another self-signed one.

2013/12/25 R. David Murray :
> So all the buildbots are red for the moment.
>
> A mixture of red and green would have been more appropriate for
> today, I think :)
>
> --David
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PyCon Language Summit: Wednesday 9th April

[Benjamin Peterson]

2013/12/4 Christian Heimes :
> Am 04.12.2013 20:07, schrieb Benjamin Peterson:
>> FWIW, the current plan is to have the last normal release in 2015
>> and security releases "indefinitely" (2020 or something like
>> that).
>
> Can we make an exception for platform support, e.g. compatibility
> fixes with new compiler or library versions? dpkg-architecture and
> OpenSSL with SSLv2 have broken Python 2.6 builds.

In general, yes.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PyCon Language Summit: Wednesday 9th April

[Benjamin Peterson]

2013/12/4 Barry Warsaw :
> On Dec 04, 2013, at 07:15 PM, Antoine Pitrou wrote:
>
>>As for the question, I think we should wait at least two or three years
>>before "sunsetting" 2.7.
>
> I've been thinking we should move Python 2.7 to security-fix only around the
> Python 3.5 time frame, with a couple more years of promised security support.

FWIW, the current plan is to have the last normal release in 2015 and
security releases "indefinitely" (2020 or something like that).



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7.6

[Benjamin Peterson]

I know I said I would do Python 2.7.6 this weekend, but I became
unexpectedly busy. I will plan to get to it in the next few days.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Closing the 2.6 branch?

[Benjamin Peterson]

2013/10/30 Barry Warsaw :
> Now that 2.6.9 is out, I wonder if there's anything we can or should do to the
> Mercurial repository to explicitly prevent commits to the 2.6 branch?  We have
> we done to older branches?

I've now disabled pushing to the 2.6 branch.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] Python 3.4.0a4: Coming In For A Bumpy Landing

[Benjamin Peterson]

2013/10/20 Ned Deily :
>
> On Oct 20, 2013, at 15:57 , Benjamin Peterson  wrote:
>
>> 2013/10/20 Larry Hastings :
>>>
>>>
>>> 3.4.0a4 is tagged and I'm in the process of releasing it.  But it's going to
>>> be, let's say, more "alpha-quality" than the previous alphas.
>>>
>>> Known problems:
>>>
>>> There's a reference count leak in the compiler.
>>
>> This is fixed, so you could just move the tag up a bit.
>
>
> Unfortunately, the Windows and OS X installers have already been manufactured 
> so we would either have to redo them or document that there is a discrepancy 
> between the source and binary releases.  Probably not a big deal in any case 
> for an alpha release.

Ah, I didn't realize the release process had gotten that far. Carry on.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] Python 3.4.0a4: Coming In For A Bumpy Landing

[Benjamin Peterson]

2013/10/20 Larry Hastings :
>
>
> 3.4.0a4 is tagged and I'm in the process of releasing it.  But it's going to
> be, let's say, more "alpha-quality" than the previous alphas.
>
> Known problems:
>
> There's a reference count leak in the compiler.

This is fixed, so you could just move the tag up a bit.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Timeframe for 2.7.6

[Benjamin Peterson]

Fall 2013.

2013/8/16 Jesus Cea :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Is there any release date/estimation for 2.7.6?.
>
> - --
> Jesús Cea Avión _/_/  _/_/_/_/_/_/
> j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
> Twitter: @jcea_/_/_/_/  _/_/_/_/_/
> jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
> "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 Thunderbird - http://www.enigmail.net/
>
> iQCVAwUBUg4/M5lgi5GaxT1NAQIhhQP/YzvPcA9KWNYD8k5S1vNFVi3Qv3STS0UA
> 1ROP7cD7WIAWalGdRF7TrYVifHFNqfdNR84QYGU6oHGOkGBZMwlUFu9mxbrbsllh
> GrfmrTQih41xxAqUf1rkqoCmW36YO0TsCw7nNzAIJ0foveEWRPRsti8Z1/0U4Zn6
> HWeZF57rCBM=
> =oRD8
> -END PGP SIGNATURE-
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Can I get the keys to the website please?

[Benjamin Peterson]

You should already have access to the website repo.

2013/8/3 Larry Hastings :
>
>
> PEP 101 tells me that in order to release Python 3.4.0a1 I must massage the
> website.  I foolishly left this to the last minute.  Can anybody give me
> access to the repo and shove me towards the README?  Pretty please?  I
> already have access to dinsdale and am in the "webmaster" group on there.
>
> By the way: unless something explodes last-minute, Python 3.4.0a1 will be
> based on d86aec3f61b0.
>
> Fingers crossed,
>
>
> /arry
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] IMPORTANT: Strip your repos if you pulled recently

[Benjamin Peterson]

You can just pull.

2013/7/16 Barry Warsaw :
> On Jul 16, 2013, at 09:31 AM, Benjamin Peterson wrote:
>
>>Oops, the bad one is actually
>>
>>8889c9b5dd3a
>
> Uh, then how do we unstrip the other one?  Or should we just re-clone and
> ignore this ever happened? ;)
>
> -Barry
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] IMPORTANT: Strip your repos if you pulled recently

[Benjamin Peterson]

Oops, the bad one is actually

8889c9b5dd3a

2013/7/16 Ronald Oussoren :
>
> On 16 Jul, 2013, at 18:03, Benjamin Peterson  wrote:
>
>> It should be safe to continue pulling. Those revisions you see below
>> are ones committed after I stripped the repo.
>
> Isn't the first one the stripped changeset?
>
> Ronald
>
>>
>> 2013/7/16 Ronald Oussoren :
>>>
>>> On 16 Jul, 2013, at 5:46, Benjamin Peterson  wrote:
>>>
>>>> If you have c3a510b22218 in your repo, you will need to strip it like this
>>>>
>>>> $ hg strip c3a510b22218
>>>>
>>>> (make sure to have the mq extension enabled)
>>>>
>>>> Sorry for the trouble.
>>>
>>> If I do that and run "hg incoming" I get a number of incoming changes (see 
>>> below).
>>> I did do some work before seeing your message, does that mean I've 
>>> accidently
>>> reverted your fix to the repository?
>>>
>>> Ronald
>>>
>>>
>>> ronald@gondolin[0]$ hg pull -u
>>> pulling from ssh://h...@hg.python.org/cpython
>>> searching for changes
>>> adding changesets
>>> adding manifests
>>> adding file changes
>>> added 5 changesets with 4 changes to 1 files
>>> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>>>
>>> [~/Projects/python/rw/default]
>>> ronald@gondolin[0]$ hg strip c3a510b22218
>>> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>>> saved backup bundle to 
>>> /Users/ronald/Projects/python/rw/default/.hg/strip-backup/c3a510b22218-backup.hg
>>>
>>> [~/Projects/python/rw/default]
>>> ronald@gondolin[0]$ hg incoming
>>> comparing with ssh://h...@hg.python.org/cpython
>>> searching for changes
>>> changeset:   84653:c3a510b22218
>>> branch:  3.3
>>> parent:  84651:e22dd5fda5a8
>>> user:Benjamin Peterson 
>>> date:Mon Jul 15 19:15:34 2013 -0700
>>> summary: check the return value of new_string() (closes #18470)
>>>
>>> changeset:   84654:2650127ce034
>>> parent:  84652:8a078bf3cf14
>>> parent:  84653:c3a510b22218
>>> user:Benjamin Peterson 
>>> date:Mon Jul 15 20:47:47 2013 -0700
>>> summary: merge 3.3 (closes #18470)
>>>
>>> changeset:   84655:72312ff5f712
>>> branch:  3.3
>>> parent:  84653:c3a510b22218
>>> user:Benjamin Peterson 
>>> date:Mon Jul 15 20:50:22 2013 -0700
>>> summary: move declaration to top of block
>>>
>>> changeset:   84656:daf9ea42b610
>>> parent:  84654:2650127ce034
>>> parent:  84655:72312ff5f712
>>> user:Benjamin Peterson 
>>> date:Mon Jul 15 20:50:25 2013 -0700
>>> summary: merge 3.3
>>>
>>> changeset:   84657:7272ef213b7c
>>> tag: tip
>>> user:Ronald Oussoren 
>>> date:Tue Jul 16 08:32:05 2013 +0200
>>> summary: Also remove a (broken) leaker test for the code removed in 
>>> issue #18393.
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> Benjamin
>



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] IMPORTANT: Strip your repos if you pulled recently

[Benjamin Peterson]

You should be completely safe if you didn't pull at all yesterday.

2013/7/16 Terry Reedy :
>
>
> On 7/15/2013 11:46 PM, Benjamin Peterson wrote:
>>
>> If you have c3a510b22218 in your repo, you will need to strip it like this
>>
>> $ hg strip c3a510b22218
>>
>> (make sure to have the mq extension enabled)
>
>
> Does the subject mean that if I have not pulled recently (a day, at least),
> it will not get pulled? (because of having been stripped from the repo)?
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] IMPORTANT: Strip your repos if you pulled recently

[Benjamin Peterson]

It should be safe to continue pulling. Those revisions you see below
are ones committed after I stripped the repo.

2013/7/16 Ronald Oussoren :
>
> On 16 Jul, 2013, at 5:46, Benjamin Peterson  wrote:
>
>> If you have c3a510b22218 in your repo, you will need to strip it like this
>>
>> $ hg strip c3a510b22218
>>
>> (make sure to have the mq extension enabled)
>>
>> Sorry for the trouble.
>
> If I do that and run "hg incoming" I get a number of incoming changes (see 
> below).
> I did do some work before seeing your message, does that mean I've accidently
> reverted your fix to the repository?
>
> Ronald
>
>
> ronald@gondolin[0]$ hg pull -u
> pulling from ssh://h...@hg.python.org/cpython
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 5 changesets with 4 changes to 1 files
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> [~/Projects/python/rw/default]
> ronald@gondolin[0]$ hg strip c3a510b22218
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> saved backup bundle to 
> /Users/ronald/Projects/python/rw/default/.hg/strip-backup/c3a510b22218-backup.hg
>
> [~/Projects/python/rw/default]
> ronald@gondolin[0]$ hg incoming
> comparing with ssh://h...@hg.python.org/cpython
> searching for changes
> changeset:   84653:c3a510b22218
> branch:  3.3
> parent:  84651:e22dd5fda5a8
> user:Benjamin Peterson 
> date:Mon Jul 15 19:15:34 2013 -0700
> summary: check the return value of new_string() (closes #18470)
>
> changeset:   84654:2650127ce034
> parent:  84652:8a078bf3cf14
> parent:  84653:c3a510b22218
> user:Benjamin Peterson 
> date:    Mon Jul 15 20:47:47 2013 -0700
> summary: merge 3.3 (closes #18470)
>
> changeset:   84655:72312ff5f712
> branch:  3.3
> parent:  84653:c3a510b22218
> user:Benjamin Peterson 
> date:    Mon Jul 15 20:50:22 2013 -0700
> summary: move declaration to top of block
>
> changeset:   84656:daf9ea42b610
> parent:  84654:2650127ce034
> parent:  84655:72312ff5f712
> user:Benjamin Peterson 
> date:Mon Jul 15 20:50:25 2013 -0700
> summary: merge 3.3
>
> changeset:   84657:7272ef213b7c
> tag: tip
> user:Ronald Oussoren 
> date:Tue Jul 16 08:32:05 2013 +0200
> summary: Also remove a (broken) leaker test for the code removed in issue 
> #18393.
>
>



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] I would suggest not pushing or pulling from the repo

[Benjamin Peterson]

Okay, I fixed the repo. You may need to strip your repo per my last mail.

2013/7/15 Benjamin Peterson :
> I accidently pushed a merge from 3.3 to default in the "3.3" branch. I
> think I'm going to have to strip it.
>
> --
> Regards,
> Benjamin



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] IMPORTANT: Strip your repos if you pulled recently

[Benjamin Peterson]

If you have c3a510b22218 in your repo, you will need to strip it like this

$ hg strip c3a510b22218

(make sure to have the mq extension enabled)

Sorry for the trouble.



--
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] I would suggest not pushing or pulling from the repo

[Benjamin Peterson]

There's no unwanted head to close. It's all on the 3.3 branch.

2013/7/15 Jason R. Coombs :
> The other option is you could 'close' the unwanted head and create a new
> head at the point before the unwanted merge.
>
>> -Original Message-
>> From: python-committers [mailto:python-committers-
>> bounces+jaraco=jaraco@python.org] On Behalf Of Benjamin Peterson
>> Sent: Monday, 15 July, 2013 23:08
>> To: python-committers
>> Subject: [python-committers] I would suggest not pushing or pulling from
>> the repo
>>
>> I accidently pushed a merge from 3.3 to default in the "3.3" branch. I
> think I'm
>> going to have to strip it.
>>
>> --
>> Regards,
>> Benjamin
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> http://mail.python.org/mailman/listinfo/python-committers



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] I would suggest not pushing or pulling from the repo

[Benjamin Peterson]

I accidently pushed a merge from 3.3 to default in the "3.3" branch. I
think I'm going to have to strip it.

--
Regards,
Benjamin
___
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

[Benjamin Peterson]

2013/6/25 Larry Hastings :
> I'm not questioning the decision--I'm asking, what is the heuristic I can
> apply in the future to predict whether or not a change will be accepted into
> the 2.7 branch.  My current heuristic ("only bad bug fixes") seems to be on
> the fritz.

I realize everyone wants a nice heuristic. Unfortunately, I don't
think one exists that explains why every change does or does not land
in 2.7.



--
Regards,
Benjamin
___
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

[Benjamin Peterson]

2013/6/22 Eli Bendersky :
> 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?

PEP 373 is better given in that it deals with 2.7 and not a
non-existent 2.8 release. :)

I agree not every theoretically applicable bugfix needs to land in
2.7. If it's been broken for all of the 2.x series, it probably
doesn't need to be fixed now. (The most important bugs to fix are the
ones we introduced in the last bugfix release.) I'm also open to and
have been open to build system changes that keep Python compiling even
though they can break things (see cross-compiling). Even limited
not-build system "features" like retrofitting bsddb so it could
compile with a non-ancient version of bsddb can be acceptable.



--
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] hg clone cpython newrepo aborts

[Benjamin Peterson]

2013/5/28 Senthil Kumaran :
>
> On Tue, May 28, 2013 at 7:19 AM, Dirkjan Ochtman  wrote:
>>
>> On Tue, May 28, 2013 at 4:11 PM, Senthil Kumaran 
>> wrote:
>> > While trying to clone a cpython repo to a new repo. I am getting this
>> > error.
>> >
>> > getting Lib/idlelib/idle.bat
>> > getting Lib/idlelib/idle.py
>> > getting Lib/idlelib/idle.pyw
>> > getting Lib/idlelib/idle_test/@README.txt
>> > abort: data/Lib/idlelib/idle_test/@README.txt.i@7573717b9e6f: no match
>> > found!
>> >
>> > Is something wrong with the repo?
>>
>> It's possible something broke with the @-filename. Have you tried hg
>> verify yet?
>>
>
> $ hg verify
> repository uses revlog format 1
> checking changesets
> checking manifests
> crosschecking files in changesets and manifests
> checking files
>  data/Lib/idlelib/idle_test/@README.txt.i@83941: missing revlog!
>  83941: empty or missing Lib/idlelib/idle_test/@README.txt
>  Lib/idlelib/idle_test/@README.txt@83941: 7573717b9e6f in manifests not
> found
> warning: copy source of 'Modules/_threadmodule.c' not in parents of
> 60ad83716733
> warning: copy source of 'Objects/bytesobject.c' not in parents of
> 64bb1d258322
> warning: copy source of 'Objects/stringobject.c' not in parents of
> 357e268e7c5f
> 9872 files, 83957 changesets, 185453 total revisions
> 3 warnings encountered!
> 3 integrity errors encountered!
> (first damaged changeset appears to be 83941)
>
>
> // All these are from my local repo, which i keep updated. I am cloning from
> hg.python.org to see if this problem persists.

 I think you need to upgrade hg.

--
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[Benjamin Peterson]

2013/5/24 Brett Cannon :
> It's an extreme example, but for instance I added an entry for this
> sys.modules change where I just added a clarifying sentence. Probably
> not needed but wanted to make sure that people got the message they
> shouldn't replace sys.modules.

Does anybody actually ready Misc/NEWS?


--
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7.4rc1 tagged

[Benjamin Peterson]

The 2.7.4rc1 tag is in the main hg repo.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)

[Benjamin Peterson]

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
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.3.1 two months away?

[Benjamin Peterson]

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
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)

[Benjamin Peterson]

2012/9/30 Jesus Cea :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 29/09/12 10:35, Georg Brandl wrote:
>> Until the last ordinary 3.2 bugfix release is done (which will be
>> soon), the usual procedure for 3.x will be to check into 3.2, merge
>> into 3.3, and then merge into default, except of course for a)
>> fixes of 3.3-only features and b) trivial things like typos that
>> you don't feel have to be in 3.2.4.
>>
>> default is now Python 3.4, and new features can be committed
>> there.
>
> So, if I understand correctly, the current situation is this:
>
> 2.6: Security fixes only
> 2.7, 3.2, 3.3: Bugfixes only
> 2.3, 2.4, 2.5, 3.0, 3.1: Dead

3.1 still recieves security fixes.

>
> After 3.2.4 is published ("soon"), 3.2 would move to "security fixes
> only". Am I right?
>
> I wonder if we have a deadline for supporting 2.6 yet. How about 2.7?.

2.7 will get at least 5 years of support.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Cutting 3.3 branch now. Why not?

[Benjamin Peterson]

2012/6/28 Jesus Cea :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Python 3.3 is currently in beta, so the rythm of new patches in
> "default" will decrease and people with new features MUST wait until
> 3.3 is out. I think this is a waste of time. And even if people is
> working with HG private clones, they can't test using the buildbots
> neither mark a bug as fixed in the tracker.
>
> If we create a new 3.3 branch *NOW* and add it to the buildbots,
> people can keep working in "default" full speed (for 3.4), while 3.3
> branch is getting ready for general release. We only need to remember
> to appy the same rule current rule: any patch in branch "x" must be
> "merged" into branch "x+1" too.
>
> Has this step been considered?. I think it is a nice improvement that
> HG enables and we are not using.
>
> What do you think?.

I, for one, had my fill of maintaining 4 branches when we were doing
two versions of 2.x and two versions of 3.x.

People are free to put their features in their own private clones and
await 3.4 development beginning.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] state of repo?

[Benjamin Peterson]

2012/4/5 R. David Murray :
> I just tried to merge a change from 3.2 to default and found an unexpected
> file being merged.  Looking at the graph, it *looks* like Sandro copied a
> change to default instead of merging it, even though his commit comment
> says merge.  That would be fine, I'd just do a null merge...except that
> the file I'm being asked to merge when I try that seems to have nothing
> to do with Sandro's commits.  It is deleting one paragraph and adding
> another in the threading docs.

Yes, it seems he didn't actually perform a merge.

>
> Can someone sort this out, please?  It's currently beyond my knowledge
> of hg to do so.

Fixed.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Time to cut new rc2 release candidates - expat DoS fix is in

[Benjamin Peterson]

2012/3/15 Barry Warsaw :
> On Mar 15, 2012, at 08:32 AM, Georg Brandl wrote:
>
>>Thanks.  I will do the tagging and packaging on Saturday.
>
> I'll do the same for 2.6.

I'm traveling this weekend, so I'll probably tag today or tomorrow.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Time to cut new rc2 release candidates - expat DoS fix is in

[Benjamin Peterson]

2012/3/14 Gregory P. Smith :
> The fixes for the expat hash randomization DoS are in and working -
> http://bugs.python.org/issue14234.  New stable and security fix rc2 release
> candidates should be created for 2.6, 2.7, 3.1 and 3.2.

Okay. Can you tell me the commits I need to transplant to the 2.7
release branch?


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] security and bugfix releases tagged

[Benjamin Peterson]

2012/2/25 "Martin v. Löwis" :
>>> Am 24.02.2012 17:49, schrieb Benjamin Peterson:
>>>> Hi Ned and Martin,
>>>> 2.7.3rc1 and 3.2.3rc1 are tagged in the repo ready for binaries.
>>>
>>>  1b605fb13977c887a9554a9896b8  16081986  python-2.7.3rc1-pdb.zip
>>>  53439ec0110345225f5f0951f00bc387  17220674  python-2.7.3rc1.amd64-pdb.zip
>>>  492b9357486701a58834064ee8d2db82  16449536  python-2.7.3rc1.amd64.msi
>>>  c6ec01bc1f0e5bf20c034345ff7ca43c  15998976  python-2.7.3rc1.msi
>>>  4314d142f060863079b9c5d1290b42c4  18225122  python-3.2.3rc1-pdb.zip
>>>  13aafd78aee3af8039a9eaee9d36d909  19989576  python-3.2.3rc1.amd64-pdb.zip
>>>  c2295f029e55eb93bebef0e721f17669  18579456  python-3.2.3rc1.amd64.msi
>>>  03d83c331417693e8256dd69d8ee2d73  17956864  python-3.2.3rc1.msi
>
> Georg introduced the procedure that they are in the ftp folder, along
> with the files. I quite like that, since there is no need to check them
> in. If you want to continue with the past tradition, feel free to copy
> them into svn, though:
>
> http://www.python.org/ftp/python/2.7.3/python-2.7.3rc1.msi.asc
> etc.

I think that's a good idea, too.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] security and bugfix releases tagged

[Benjamin Peterson]

Thank you. Do you want to add signatures?

2012/2/24 "Martin v. Löwis" :
> Am 24.02.2012 17:49, schrieb Benjamin Peterson:
>> Hi Ned and Martin,
>> 2.7.3rc1 and 3.2.3rc1 are tagged in the repo ready for binaries.
>
>  1b605fb13977c887a9554a9896b8  16081986  python-2.7.3rc1-pdb.zip
>  53439ec0110345225f5f0951f00bc387  17220674  python-2.7.3rc1.amd64-pdb.zip
>  492b9357486701a58834064ee8d2db82  16449536  python-2.7.3rc1.amd64.msi
>  c6ec01bc1f0e5bf20c034345ff7ca43c  15998976  python-2.7.3rc1.msi
>  4314d142f060863079b9c5d1290b42c4  18225122  python-3.2.3rc1-pdb.zip
>  13aafd78aee3af8039a9eaee9d36d909  19989576  python-3.2.3rc1.amd64-pdb.zip
>  c2295f029e55eb93bebef0e721f17669  18579456  python-3.2.3rc1.amd64.msi
>  03d83c331417693e8256dd69d8ee2d73  17956864  python-3.2.3rc1.msi
>
> Regards,
> Martin



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] security and bugfix releases tagged

[Benjamin Peterson]

Hi Ned and Martin,
2.7.3rc1 and 3.2.3rc1 are tagged in the repo ready for binaries.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.2 branch in mercurial

[Benjamin Peterson]

2012/1/4 Senthil Kumaran :
> I think, there is something wrong with state of hg.python.org at the moment.
>
> On a fresh clone from hg.python.org
>
> $hg clone ssh://h...@hg.python.org/cpython cpython
>
> If I do, hg branches, the 3.2 is shown as inactive. Did something
> change recently?

It just means you need to merge changes from upstream in the same
branch with your changes.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Pulling from contributors repositories

[Benjamin Peterson]

2011/6/12 Ned Deily :
> There are several ways we could eliminate this needless pain.  Probably
> the simplest would be to agree on a simple format for including the NEWS
> and ACK info in the hg commit message and then agree on a process to
> batch update the NEWS and ACK files from the commit messages prior to
> each release.

The problem with this method is that spelling can't be fixed and
messages can't be reformatted or expanded.

Another method would be to write a extension for Mercurial which is
"smart" about the format of Misc/NEWS and could do the resolution
automatically.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7.2 and 3.1.4 tagged

[Benjamin Peterson]

Hi,
2.7.2 and 3.1.4 have been tagged (in the main repo) and are ready for
binary building.


Thanks,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] state of the 3.2 branch

[Benjamin Peterson]

2011/6/8 R. David Murray :
> I am completely confused by the state of the 3.2 branch.  My understanding
> is that RC1 has been released, that RC2 is coming soon, and that Georg
> is releasing 3.2.1 from a separate clone so that we do not have to have
> a freeze in the main repo.  All that is fine, but the main repo NEWS
> file is headed by "What's New in Python 3.2.1 Release candidate 2?",
> yet there are clearly news items in that section that should not be
> going in to release candidate 2.  As an arbitrary example, take:
>
>    - Issue #12175: FileIO.readall() now raises a ValueError instead of
>      an IOError if the file is closed.
>
> That seems to me to be clearly not a critical fix, and thus not
> appropriate for the RC stage.
>
> Is is that the NEWS section hasn't been updated?  Or, Georg, are you
> going to sort out the stuff you really put into RC2 from the other stuff
> after you release RC2?

See af715726d911 It looks like Georg has been merging the 3.2.1
release branch to the 3.2 branch and people are blindly adding to the
news section. That stuff should probably just be relocated.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 2.7.2 and 3.1.4 rc now

[Benjamin Peterson]

2011/5/31 "Martin v. Löwis" :
> Am 30.05.2011 23:36, schrieb Benjamin Peterson:
>> 2011/5/30 Victor Stinner :
>>> Le dimanche 29 mai 2011 22:55:17, Benjamin Peterson a écrit :
>>>> Hi,
>>>> I'm going to start spinning those releases now. I'll make a branch for
>>>> 2.7.2 but not for 3.1.4. Please stop committing to 3.1; it's going
>>>> into security only mode.
>>>
>>> I would like to commit something into the 2.7 branch. The NEWS file starts
>>> with:
>>>
>>> What's New in Python 2.7.2?
>>> ===
>>>
>>> *Release date: 2011-05-29*
>>>
>>> Python 2.7.2 was released yesterday, or was it the RC1?
>>>
>>> I don't care if my commit (better fix for #1195) doesn't go into Python 
>>> 2.7.2,
>>> so should I start an empty "Python 2.7.3" section?
>>
>> Yes, go ahead.
>
> Really??? I have some changes that I need to commit to 2.7 that do need
> to go into 2.7.2. So how are you going to manage these?

I have a release branch from the 2.7.2rc1. It's currently, local, but
I will push it (when I get to a computer with my .ssh keys), so you
can apply any changes you need to it. Then after 2.7.2, I will merge
it to the 2.7 branch.

>
> I rather recommend that the 2.7 branch is frozen until the final
> release, and any changes are only merged afterwards.




-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 2.7.2 and 3.1.4 rc now

[Benjamin Peterson]

2011/5/30 Victor Stinner :
> Le dimanche 29 mai 2011 22:55:17, Benjamin Peterson a écrit :
>> Hi,
>> I'm going to start spinning those releases now. I'll make a branch for
>> 2.7.2 but not for 3.1.4. Please stop committing to 3.1; it's going
>> into security only mode.
>
> I would like to commit something into the 2.7 branch. The NEWS file starts
> with:
>
> What's New in Python 2.7.2?
> ===
>
> *Release date: 2011-05-29*
>
> Python 2.7.2 was released yesterday, or was it the RC1?
>
> I don't care if my commit (better fix for #1195) doesn't go into Python 2.7.2,
> so should I start an empty "Python 2.7.3" section?

Yes, go ahead.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 2.7.2 and 3.1.4 rc now

[Benjamin Peterson]

2011/5/29 Victor Stinner :
> Le dimanche 29 mai 2011 22:55:17, Benjamin Peterson a écrit :
>> Hi,
>> I'm going to start spinning those releases now. I'll make a branch for
>> 2.7.2 but not for 3.1.4. Please stop committing to 3.1; it's going
>> into security only mode.
>
> Just to be sure, you mean the 3.1.4 will be the last bugfix release? 3.1.5 
> will
> be security fix only? So for example, as Python 2.6, doc updates are no more
> accepted in 3.1?

Correct.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7.2 and 3.1.4 rc now

[Benjamin Peterson]

Hi,
I'm going to start spinning those releases now. I'll make a branch for
2.7.2 but not for 3.1.4. Please stop committing to 3.1; it's going
into security only mode.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Committer rights for Nadeem Vawda

[Benjamin Peterson]

2011/4/7 Jesus Cea :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/04/11 22:41, Antoine Pitrou wrote:
>> Le jeudi 07 avril 2011 à 10:27 -0700, Brett Cannon a écrit :
>>> The devguide knows all: http://docs.python.org/devguide/coredev.html
>>
>> Hmmm so I assume Nadeem should send his SSH key to pydot...@python.org?
>> Or?
>
> What is preventing me to send a fake SSH key to that acount, from a
> gmail address, saying "hi, this is Nadeem. You are waiting for this" ;-).

Well, that would be fairly pointless considering you already have
commit privs...



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] branches are open

[Benjamin Peterson]

2011/2/21 Georg Brandl :
> py3k is now 3.3a0, and I've created a new release32-maint branch.
> Thanks to Martin for setting up svnmerge on the new branch; please
> merge all bug fixes to release32-maint as usual.
>
> Benjamin, how long will you want to maintain 3.1 in bugfix mode?

I will try to release sometime this spring as soon as I have time.
Don't feel obliged to backport everything.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Blocking feature backports

[Benjamin Peterson]

2010/12/1 Terry Reedy :
> I would like to commit a couple of new feature patches in the next couple of
> days for #9299 (if no one else does it) and #10534 (working on that).  It
> appears to be somewhat customary to follow such patches with 3.1/2.7 blocks,
> but Georg implied in another message that the process is obsolete in that no
> one is doing blind mass merges anymore, and I apparently cannot do blocks
> with TortoiseSvn. So is it alright if I make the commits and simply note in
> the commit messages that they are for a new feature and should not be merged
> backwards?

Please only use svnmerge if it helps you. I just use it to backport
things from py3k because it provides commit messages.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7.* and 3.1.* branches open

[Benjamin Peterson]

With 2.7.1 and 3.1.3 out, the maintenance branches are again open. I
would expect 3.1.4 and 2.7.2 to be released in the June/July area.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7.1 and 3.1.3 today

[Benjamin Peterson]

I'm going to start working on the releases now, so the maintenance
branches are now closed.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] maintenance branches are open

[Benjamin Peterson]

2010/11/20 Éric Araujo :
>> 2.7.1rc1 and 3.1.3rc1 are released, so their branches are open now.
>> Please only very safe bug fixes until final (two weeks).
>
> I’m afraid I can’t define what a very safe fix is.  I think I won’t
> merge anything for another week and then suffer the pains of svnmerge
> multiple revisions in a row.  Is it okay to make you nosy on bugs I fix
> in 3.2 to ask you if they are very safe?

By all means. Or ask on irc.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] maintenance branches are open

[Benjamin Peterson]

2.7.1rc1 and 3.1.3rc1 are released, so their branches are open now.
Please only very safe bug fixes until final (two weeks).

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7 and 3.1 branches frozen for RC

[Benjamin Peterson]

All branches are closed now. I'll be on #python-dev and on email if you need me.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Deny nonbreaking spaces in the precommit script?

[Benjamin Peterson]

2010/11/8 Łukasz Langa :
> Am 07.11.2010 19:28, schrieb Benjamin Peterson:
>>
>> 2010/11/7 Victor Stinner:
>>>
>>> I would like to know if it would be
>>> possible to block a commit introducing nonbreaking spaces? A least for me
>>> :-)
>>
>> I don't think add pre-commit hooks for every conceivable mistake is
>> the right way to go.
>
> I see you're basically saying "We're all adults here" and that we should be
> able to control our own environment so these kinds of commits don't happen
> (like Guido said). Well guess what, I believe that isn't going to work. Let
> me tell you why.
>
> 1. Most* contributors work on Python in their spare time. That means they
> also have jobs, families, all kinds of everyday trouble. Even if 99% of the
> time their performance is stellar, there will be times when some stupid
> errors get through.
>
> 2. We invite more contributors now which means there are going to be more
> rookies than ever before. I for one am an example of that. You either expect
> newbies to perform like their own mentors from day one or expect mentors to
> waste time working out dumb rookie mistakes made because of a misconfigured
> environment, etc.
>
> 3. Speaking of environments, they change. Software evolves, people switch
> machines, operating systems, editors, toolchains. If one Debian veteran
> switches to Mac OS X and makes some error because of false assumptions,
> misconfigured software, whatever... his experience should prevent other
> people from making the same mistake in the future.
>
> I could go on and risk boring you to death. The point is, if we can automate
> stuff out of the workflow, we should definitely do it. Each and every time.
> We don't gain anything by not implementing automation.

I don't think you can ever automate "checking for mistakes" out of the
workflow. There will never be a commit hook that checks whether you
created a race condition or deference possibly uninitialized memory.
IMO, if you're unwilling to be looking for simple and complex bugs,
you should think twice before committing at all.

>
> Even if that commit hook prevents a single wrong commit a year, it's worth
> it. As unpaid volunteers, we don't have time for hunting the same mistakes
> twice.
>
> One last disclaimer. I'm not a native speaker so if the tone of my post
> sounds offensive or rude, I apologise in advance because that was not my
> intention. OTOH, the zen says explicit is better than diplomatic. Or
> something like that.




-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Deny nonbreaking spaces in the precommit script?

[Benjamin Peterson]

2010/11/7 Victor Stinner :
> Hi,
>
> I introduced nonbreaking spaces in Lib/os.py in a comment, because I kept Alt
> Gr. key pressed to write the space after # (stupid Xorg keyboard variant!).
>
> This change introduces a strange bug in "LANG=C ./python -m test.regrtest -v
> test_imp test_trace" command.
>
> The real bug was fixed in issue #10329, but I would like to know if it would 
> be
> possible to block a commit introducing nonbreaking spaces? A least for me :-)

I don't think add pre-commit hooks for every conceivable mistake is
the right way to go.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] JetBrains PyCharm license for the team

[Benjamin Peterson]

2010/10/22 Georg Brandl :
> Am 22.10.2010 20:53, schrieb Brett Cannon:
>> On Fri, Oct 22, 2010 at 10:53, Georg Brandl  wrote:
>>> Am 22.10.2010 19:33, schrieb Brett Cannon:
 JetBrains has granted us a group FLOSS license for PyCharm:
 http://www.jetbrains.com/pycharm/ . It's good for a year for
 non-commercial use. If you would like a copy of the license just email
 me and I will send it to you.

 As for how it is, I have not used it yet, but Richard Jones can't stop
 raving about it (and he's a Vim user! =).
>>>
>>> Does it come with an IRC client and Tetris?
>>
>> Apparently: http://plugins.intellij.net/plugin/?&id=118 and
>> http://plugins.intellij.net/plugin/?id=1175 .
>
> Then I'd like to try it :)

Gee, I think M-x butterfly is a lot more important, but I'd also like to try.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP checkin process

[Benjamin Peterson]

2010/7/22 Nick Coghlan :
> On Thu, Jul 22, 2010 at 6:35 PM, Barry Warsaw  wrote:
>> On Jul 22, 2010, at 08:17 AM, Nick Coghlan wrote:
>>
>>>Useful commands (using PEP 3150 as my example):
>>>python genpepindex.py # ./genpepindex.py only works if Python 2.5 is
>>>installed ./pep2html.py -b 3150 # Generate the PEP and open in a new
>>>browser window ./pep2html.py 3150 # Regenerate the PEP (hit refresh in
>>>the browser to see changes)
>>
>> Just run 'make' in the peps checkout directory.
>
> That doesn't work for me by default since I don't have python2.5
> installed (although it does turn out it can be made to work by
> overriding PYTHON as Benjamin suggests). Not only that, but the
> makefile builds all the PEPs when I generally only care about the PEP
> I'm working on and PEP 0.

Note that dinsdale's python version is now up to 2.5, so the prefix
can be (and has been) removed.



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP checkin process

[Benjamin Peterson]

2010/7/21 Nick Coghlan :
> On Thu, Jul 22, 2010 at 2:15 AM, Guido van Rossum  wrote:
>> You can check in directly. The peps@ list is only for PEP authors
>> without checkin privileges, or if you're not sure you have conformed
>> to the PEP template sufficiently well. Picking a PEP number is
>> arbitrated by svn (soon hopefully Hg). However always to make sure
>> that your pep runs through pep2html without warnings or errors.
>
> These days running genpepindex.py is also useful to make sure you
> don't break the generation of PEP 0 (e.g. I found an error in the way
> I had written the headers for PEP 3150 when I did that).
>
> Useful commands (using PEP 3150 as my example):
> python genpepindex.py # ./genpepindex.py only works if Python 2.5 is installed

You can also do "make PYTHON=python"



-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 2.7 almost out the door

[Benjamin Peterson]

2010/7/3 Alexander Belopolsky :
> The "What’s New in Python 2.7" document says "Python 2.7 was released
> on July 7, 2010."  Is this a typo or you plan a 4-day cool off period
> before making an announcement?

I was thinking of July being the 7th month when I did that.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] 2.7 almost out the door

[Benjamin Peterson]

2.7 has been tagged, and I have uploaded docs and the source tarballs
to python.org. I will wait on binaries before announcing the release.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] churning 2.7

[Benjamin Peterson]

The last release blockers have been closed, so I'm now going to go
ahead if the release. Please no commits to the trunk... ever again! :)

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] changes after 2.7 final

[Benjamin Peterson]

After I tag 2.7 this Saturday, I will effect the following changes in
the repository:
- I will make the 2.7 maintenance branch.
- I will remove svnmerge from trunk -> py3k.
- I will initialize svnmerge from py3k -> 2.7maint.
- The trunk will be officially closed. I suggest you just delete your
trunk working copies (or switch them anyway) because a commit hook
will be in place to prevent commits to it.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Delaying 3.2 release

[Benjamin Peterson]

2010/6/30 Georg Brandl :
> All in all, hearing the arguments in this thread I agree that a month
> more time for development is a good thing, and I will update the release
> schedule accordingly.

You could just throw in another alpha. It never hurts to get the code
out there IMO.


-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] trunk open

[Benjamin Peterson]

The final release is next, so there really should be excellent reasons
to change things in the trunk now.

-- 
Regards,
Benjamin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers