[python-committers] Re: Commits are no longer noted in bro issues

[Guido van Rossum]

Did you check your junk or spam mail folders? The email address from which
bpo is sending email is not super trusted by the spam filters used by large
email providers like GMail and Outlook.

On Thu, May 27, 2021 at 10:46 AM Irit Katriel 
wrote:

>
> I'm not getting anything at all from bpo for about a week now. Maybe it
> had enough of me.
>
> On Thu, May 27, 2021 at 6:01 PM Victor Stinner 
> wrote:
>
>> I confirm that commits merged in 3.9, 3.10 and main branches are
>> logged again in bugs.python.org. Thanks to everyone who helped to
>> solve this issue!
>>
>
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/OTZWI4KRXWFZJOR4LJJM66N2XL6EVWYW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Restarting individual CI runs

[Guido van Rossum]

Quite frequently I see PRs that have all but one test green, and one test
just hanging for a long time (e.g. 19 hours). It would be useful to have
the ability to restart a particular test rather than re-running all tests
(by closing and reopening the PR). Does this functionality exist? IIRC on
Travis-CI it did exist, but only for privileged users. Does GitHub Actions
have such a thing?

Example: https://github.com/python/cpython/pull/25551 -- the Address
Sanitizer run has been waiting for 19 hours.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/X4KPYUNKZWLRZ5GQDZWXTE5Y4WGSHSA6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Restarting individual CI runs

[Guido van Rossum]

That's too bad, we really should ask for this.

A timeout on a job still marks it as failed, I presume, so we still have to
restart all jobs... :-(

On Tue, Jun 22, 2021 at 12:40 PM Alex Gaynor  wrote:

> Github actions doesn't have the ability to restart individual jobs,
> sadly (I've asked for this when they've done research sessions).
>
> FWIW, I'd recommend adding a timeout to jobs (it can be set in the YML
> file), that way hung jobs don't hang for hours and hours.
>
> Alex
>
> On Tue, Jun 22, 2021 at 3:16 PM Guido van Rossum  wrote:
> >
> > Quite frequently I see PRs that have all but one test green, and one
> test just hanging for a long time (e.g. 19 hours). It would be useful to
> have the ability to restart a particular test rather than re-running all
> tests (by closing and reopening the PR). Does this functionality exist?
> IIRC on Travis-CI it did exist, but only for privileged users. Does GitHub
> Actions have such a thing?
> >
> > Example: https://github.com/python/cpython/pull/25551 -- the Address
> Sanitizer run has been waiting for 19 hours.
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> > Pronouns: he/him (why is my pronoun here?)
> > ___
> > 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/X4KPYUNKZWLRZ5GQDZWXTE5Y4WGSHSA6/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> All that is necessary for evil to succeed is for good people to do nothing.
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/53LVUSAARNMVVRRM746QO6BRFJMKAW6G/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Restarting individual CI runs

[Guido van Rossum]

Well, the 19 hours was just that I came back to the PR after 19 hours and
it was still not finished. I suspect that some message was just lost, and
either it never ran or was never marked as complete. :-)

On Tue, Jun 22, 2021 at 12:56 PM Alex Gaynor  wrote:

> Yes, but at least you don't have to wait 19 hours to do so (github
> actions also doesn't let you restart jobs until they're all completed,
> or cancelled I suppose).
>
> Alex
>
> On Tue, Jun 22, 2021 at 3:54 PM Guido van Rossum  wrote:
> >
> > That's too bad, we really should ask for this.
> >
> > A timeout on a job still marks it as failed, I presume, so we still have
> to restart all jobs... :-(
> >
> > On Tue, Jun 22, 2021 at 12:40 PM Alex Gaynor 
> wrote:
> >>
> >> Github actions doesn't have the ability to restart individual jobs,
> >> sadly (I've asked for this when they've done research sessions).
> >>
> >> FWIW, I'd recommend adding a timeout to jobs (it can be set in the YML
> >> file), that way hung jobs don't hang for hours and hours.
> >>
> >> Alex
> >>
> >> On Tue, Jun 22, 2021 at 3:16 PM Guido van Rossum 
> wrote:
> >> >
> >> > Quite frequently I see PRs that have all but one test green, and one
> test just hanging for a long time (e.g. 19 hours). It would be useful to
> have the ability to restart a particular test rather than re-running all
> tests (by closing and reopening the PR). Does this functionality exist?
> IIRC on Travis-CI it did exist, but only for privileged users. Does GitHub
> Actions have such a thing?
> >> >
> >> > Example: https://github.com/python/cpython/pull/25551 -- the Address
> Sanitizer run has been waiting for 19 hours.
> >> >
> >> > --
> >> > --Guido van Rossum (python.org/~guido)
> >> > Pronouns: he/him (why is my pronoun here?)
> >> > ___
> >> > 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/X4KPYUNKZWLRZ5GQDZWXTE5Y4WGSHSA6/
> >> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >>
> >>
> >>
> >> --
> >> All that is necessary for evil to succeed is for good people to do
> nothing.
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> > Pronouns: he/him (why is my pronoun here?)
>
>
>
> --
> All that is necessary for evil to succeed is for good people to do nothing.
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/FT5DM25SSILLL7IGQ2BEBTKWN6RNCG2Z/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: status of smtpd

[Guido van Rossum]

I would hope we’d remove it. It’s a toy implementation, unmaintained,
probably doesn’t support a lot of newer protocol features, and is probably
full of bugs. Hopefully nobody uses it!

On Tue, Jun 22, 2021 at 17:51 Irit Katriel via python-committers <
python-committers@python.org> wrote:

> The documentation for smtpd (https://docs.python.org/3/library/smtpd.html)
> states that " smtpd
>  should be
> considered deprecated" and recommends  aiosmtpd
> .
>
> Are we planning to remove it from the stdlib? Note that at the moment the
> smtpd module doesn't emit deprecation warnings, and aiosmtpd is not part of
> the stdlib.
>
> This came up on https://bugs.python.org/issue28533, where we were hoping
> to be able to move the (properly) deprecated asyncore and asynhat to
> test.support (because there are still a few tests that use them). It seems
> that smtpd is that last blocker for 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/KNF6YQE2O4OLJDNKSGAT4NLZUNCQ5QSH/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/NX7HLTZPYY3R7IHANDTLOXW2TTAZCUWI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Please make sure you're following good security practices with your GitHub account

[Guido van Rossum]

There’s another possible explanation. This mailing list is archived and the
archives are publicly readable.

On Tue, Jun 29, 2021 at 22:07 Tim Peters  wrote:

> Just for interest, I noticed a failed login attempt to my Github
> account about two hours ago, originating in Toronto.
>
> That's the first fishy thing Github's security log ever showed for my
> account.
>
> I do have 2FA enabled there now, so I'm not worried.
>
> Coincidence? About a week after I enabled 2FA for my Microsoft
> account, that _also_ notified me for the very first time of a failed
> login attempt.
>
> Maybe the NSA tracks when people enable 2FA, and after about a week
> gets around to making sure they can still break in ;-)
> ___
> 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/EUYIGLWM63BZLKROTGSOYSS57V3S2FU4/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/4HY35H774XX6GDWPYG2MNLI6BGFFTP6B/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Developer in Residence Weekly Report, July 12 - 18

[Guido van Rossum]

That sounds like a fantastic first week,Lukasz!

On Sat, Jul 17, 2021 at 04:29 Łukasz Langa  wrote:

> Hello there,
> finishing up on the inaugural week, number-wise we're looking as
> follows: I closed 14 issues and 54 PRs, reviewed 9 PRs, and authored 6 own
> PRs.
>
> Details at: https://lukasz.langa.pl/1c78554f-f81d-43d0-9c89-a602cafc4c5a/
>
> - Ł
> ___
> 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/BH3BXUROL23O5W3SNILHV6SP5E2OH3KN/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/EOJWX7RJDCKYIWE4VNTPC7DODL4JZ7Q3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Dennis Sweeney is now a member of the Python Triage team

[Guido van Rossum]

Great acquisition!

On Tue, Jul 27, 2021 at 18:25 Zachary Ware  wrote:

> Hi all,
>
> Just a quick note to mention that Dennis Sweeney (CC'd) has been added
> to the Python Triage team:
> https://github.com/python/core-workflow/issues/412.  Dennis has
> already been responding to new issues, and the newly added permissions
> will enable better responses and corrections to issue/PR metadata.
>
> Welcome, Dennis!
> ___
> 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/YSLNWZHDJK63HH4X4NI4LG2SN3DCCDPK/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/NKXSUDBSZIANEZ7FX4OQU3UL4JKJULV6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Ken Jin

[Guido van Rossum]

Pablo and I have started a poll to promote Ken Jin as a core developer.
For more details and the actual poll see:
https://discuss.python.org/t/vote-to-promote-ken-jin/10146

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/ALKHBXC2RAAO3PQRFSG4LAZQBOK5ROIC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Deprecation policy reminder

[Guido van Rossum]

Are there any exceptions? In the discussion about PyCode_New we've come to
the conclusion that keeping it and PyCode_NewWithPosArgs around is going to
be impossible to support, and we've found the few users of that API
(Cython) supportive of changing it incompatibly.

On Thu, Sep 2, 2021 at 3:56 AM Łukasz Langa  wrote:

> Hi there,
> I noticed some deprecation activity this week. Nice! I'd just like to
> remind everyone that we have a policy for that described in PEP 387
> <https://www.python.org/dev/peps/pep-0387/>  It's a very short PEP so I
> recommend you read it in its entirety. The important piece I want to
> highlight is that we cannot deprecate a feature in one release and remove
> it in the next one. We need at least two releases with the warning.
>
> Relevant quotes:
>
> Python's yearly release process (PEP 602
> <https://www.python.org/dev/peps/pep-0602>) means that the deprecation
> period must last at least two years.
>
>
> and:
>
> Wait for the warning to appear in at least two minor Python versions of
> the same major version, or one minor version in an older major version
> (e.g. for a warning in Python 3.10, you either wait until at least Python
> 3.12 or Python 4.0 to make the change). It's fine to wait more than two
> releases.
>
>
> Since this PEP is easy to miss, I linked it to the docs of
> DeprecationWarning in GH-28123
> <https://github.com/python/cpython/pull/28123>.
>
> Cheers,
> Ł
> ___
> 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/WZQIL3GLGO7NYC4XHBVFBHUNUJV6NWLE/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/BS2L3MDXK232Z523NTIM55ANSDRHR7VJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Deprecation policy reminder

[Guido van Rossum]

https://github.com/python/steering-council/issues/75

On Thu, Sep 2, 2021 at 8:21 AM Barry Warsaw  wrote:

> PEP 387 says:
>
> The steering council may grant exceptions to this policy. In
> particular, they may shorten the
> required deprecation period for a feature. Exceptions are only granted
> for extreme situations
> such as dangerously broken or insecure features or features no one
> could reasonably be depending
> on (e.g., support for completely obsolete platforms).
>
> I’m not sure I agree that these are the only reasons to grant an
> exception, but I guess we’ll have to discuss that.  Please do formally ask
> the SC for an exception.
>
> Cheers,
> -Barry
>
> > On Sep 2, 2021, at 08:02, Guido van Rossum  wrote:
> >
> > Are there any exceptions? In the discussion about PyCode_New we've come
> to the conclusion that keeping it and PyCode_NewWithPosArgs around is going
> to be impossible to support, and we've found the few users of that API
> (Cython) supportive of changing it incompatibly.
> >
> > On Thu, Sep 2, 2021 at 3:56 AM Łukasz Langa  wrote:
> > Hi there,
> > I noticed some deprecation activity this week. Nice! I'd just like to
> remind everyone that we have a policy for that described in PEP 387  It's a
> very short PEP so I recommend you read it in its entirety. The important
> piece I want to highlight is that we cannot deprecate a feature in one
> release and remove it in the next one. We need at least two releases with
> the warning.
> >
> > Relevant quotes:
> >
> >> Python's yearly release process (PEP 602) means that the deprecation
> period must last at least two years.
> >
> > and:
> >
> >> Wait for the warning to appear in at least two minor Python versions of
> the same major version, or one minor version in an older major version
> (e.g. for a warning in Python 3.10, you either wait until at least Python
> 3.12 or Python 4.0 to make the change). It's fine to wait more than two
> releases.
> >
> > Since this PEP is easy to miss, I linked it to the docs of
> DeprecationWarning in GH-28123.
> >
> > Cheers,
> > Ł
> > ___
> > 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/WZQIL3GLGO7NYC4XHBVFBHUNUJV6NWLE/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> > Pronouns: he/him (why is my pronoun here?)
> > ___
> > 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/BS2L3MDXK232Z523NTIM55ANSDRHR7VJ/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/5XKOEUMKPXJV3DMIZRERX7Y4XIRAKUZC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: What is github trying to tell me?

[Guido van Rossum]

I see this all the time and just ignore it. I have a feeling it's due to
the miss-islington bot being triggered by some event and checking in on the
PR while it is still transitioning. Occasionally I see a very large string
of these and assume she's just having a bad day. Also notice that in your
PR there are actually two of those failure messages, the second one being
suppressed by the GitHub UI.

But maybe Mariatta has a more reasoned explanation.

On Sat, Sep 4, 2021 at 1:47 PM Eric V. Smith  wrote:

> https://github.com/python/cpython/pull/28163 has two messages of:
>
> @ericvsmith <https://github.com/ericvsmith>: Status check is done, and
> it's a failure ❌ .
>
> Followed by the merge messages, followed by:
>
> @ericvsmith <https://github.com/ericvsmith>: Status check is done, and
> it's a success ✅ .
>
> What do the failure messages mean? Is it because I didn't wait for the
> checks to complete before merging?
>
> (It's a documentation only change that I previously committed to main
> without incident, so I didn't feel the need to wait for all of the checks
> to run before merging.)
>
> Thanks for any insight.
>
> Eric
> ___
> 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/U7A4R6TUGBD3KNAF3F2JJGNQ6V7B5G4D/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/VO4XYHUIG6KM66NONOZMMPCQYOBP6YEB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Guido van Rossum]

Interesting. Not only do you have to follow the CoC, but a more strict rule
applies as well:

"""
This email alias should not be used for personal benefit. For example,
those that use their @python.org email to solicit work for their Python
consulting work violate this rule. This can be interpreted as a PSF
endorsement of a private business, which we do not allow.
"""

On Sat, Oct 2, 2021 at 7:25 PM Benjamin Peterson 
wrote:

> 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, <
> nanjekyejoan...@gmail.com> 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/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/VWTRDPBFYRUDHZFGGXIC5HRAYXX7NZTF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Opting-in for Hacktoberfest

[Guido van Rossum]

On Fri, Oct 8, 2021 at 10:07 Mariatta  wrote:

>
> On Fri, Oct 8, 2021 at 1:08 AM Chris Withers  wrote:
>
>>
>> Don't get me wrong though: I think Hacktoberfest is a terrible idea in
>> that focusses on short-term fly-by contributing rather than fostering
>> the long term commitments that all open source projects desperately need.
>>
>>
> I understand the frustration and indeed there needs to be a solution for
> engaging long-term contributors.
> I think it's true that not everyone participating will end up as long term
> contributors, but this is a general problem, and we see the same issue with
> sprints at conferences as well. Perhaps only a small percentage of
> participants do end up being long term contributors.
> I think it's unfair to say that sprints/hacktoberfest is bad because we
> don't end up with long term commitments. It's not our place to judge
> people's motivation into contributing to OS projects. Some people have
> never been exposed to OS before, maybe they just want to try it out and see
> if it's something they want to do long term. Events like sprints and
> hacktoberfest lets them experiment and to try contributing. It's ok if most
> end up not wanting to continue. So maybe hacktoberfest is bad for
> maintainers in general, as we get very little out of it, but it can be good
> to some others. I think we should not limit ourselves into saying "only
> serious/long term contributions are allowed here".
>

Hear, hear.

For the first time this year, there is finally some focus on open source
> maintainers during hacktoberfest. Participants are also encouraged to
> donate to participating projects. Since CPython project is already set up
> on GitHub Sponsors, I would like to get CPython listed there so that our
> project will appear on the list of projects that people can donate to,
> which will help with funding of CPython development.
>

+1

I'm going to go ahead and add the hacktoberfest topic to the repo later
> today. I will also send an announcement to python-dev, letting people know
> of our participation, and that we will opt-out if we end up with mostly low
> quality and spam PRs. I will be watching the incoming PRs for the next week
> so I can determine whether we should opt-out or not.
>

Thank you!

—Guido

> --
--Guido (mobile)
___
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/6P243D7QU5MUGW65AREEZEC6GXP5U2R5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: What's the schedule for the core sprint?

[Guido van Rossum]

In the welcome channel get the attention of one of the admins (e.g. aeros)
to promote you to committer.

On Tue, Oct 19, 2021 at 11:40 AM Terry Reedy  wrote:

> I have the same question as Eric: How do I get to the sprint channels.
> ___
> 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/OZYXSUIOXRHGWGWMEEPJ5NPKZVLARBYA/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/57NVIONMAF6CIZ3NODJJ5QXQD4VK5R2L/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Sad news from Zurich

[Guido van Rossum]

A former core dev who works at Google just passed the news that Fredrik
Lundh (also known as Effbot) has died.

Fredrik was an early Python contributor (e.g. Elementtree and the 're'
module) and his enthusiasm for the language and community were inspiring
for all who encountered him or his work. He spent countless hours on
comp.lang.python answering questions from newbies and advanced users alike.

He also co-founded an early Python startup, Secret Labs AB, which among
other software released an IDE named PythonWorks. Fredrik also created the
Python Imaging Library (PIL) which is still THE way to interact with images
in Python, now most often through its Pillow fork. His effbot.org site was
a valuable resource for generations of Python users, especially its Tkinter
documentation.

Fredrik's private Facebook page contains the following message from
November 25 by Ylva Larensson (translated from Swedish):

"""

It is with such sorrow and pain that I write this. Fredrik has left us
suddenly.

"""

A core dev wrote: "I felt privileged to be able to study Fredrik's code and
to read his writing. He was a huge asset to our community in the early
days. I enjoyed his sense of humor as well. I'm sad that he passed away."

We will miss him.



-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/36Q5QBILL3QIFIA3KHNGFBNJQKXKN7SD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: GitHub mystery: "Check for source changes (pull_request)" failed

[Guido van Rossum]

The 70 different jobs were presumably the full complement of buildbots
(requested by setting a special label on the PR, which one of our GitHub
bots watches).

On Tue, Jan 11, 2022 at 9:22 PM Tim Peters  wrote:

> [Tim]
> >> Bizarre. "Check for source changes (pull_request)" apparently fixed
> >> itself by magic.
>
> [Éric Araujo ]
> > That was me! 🧙  I re-ran the workflow to see if it was a sporadic
> failure.
>
> Cool! No more or less mysterious to me than if you hadn't ;-)
>
> >> Now "Check if generated files are up to date (pull_request)" is failing
> instead
>
> > Then I saw that and looked at the github status website, which indicated
> > an issue.  Patience is the remedy!
>
> Too late! It passes now :-) After waiting a couple hours, I poked
> around until finding a button that made it try that part again. This
> time it passed.
>
> But somehow I managed to convince it run nearly 70 different jobs  A
> mystery I will happily leave uninvestigated.
>
> Thanks for chipping in!
> ___
> 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/JCJSJEXKD5F5G67REJVAD74BTYKHHSV7/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/IRDYLW43EZ3RSK7VAYCPTBRVP76MUZQN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Dependabot actions on my cpython fork

[Guido van Rossum]

This was just discussed on Discord. The upstream issue is
https://github.com/dependabot/dependabot-core/issues/2804

On Fri, Apr 1, 2022 at 14:19 Paul Moore  wrote:

> I have a cpython fork on my github account - every so often,
> dependabot kicks in and runs a whole load of actions, which I don't
> need. I'm not sure how I can switch these off, short of removing the
> .github directory (which would mean my fork has diverged from
> upstream, which I'm therefore reluctant to do).
>
> Is there a way of stopping these jobs running? APart from the annoying
> emails that I just ignore, it's a waste of computing resources for no
> good reason.
>
> Thanks,
> Paul
> ___
> 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/2X3EIPQELPKDHOE2PPT4USZATZZA256W/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/PLYALO5UGLWNJPBKM2IXJK2ED4XVR5CB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Kumar Aditya

[Guido van Rossum]

I have just opened the poll to grant core dev primileges to Kumar Aditya.

Please see details at:
https://discuss.python.org/t/vote-to-promote-kumar-aditya/21033

--Guido

-- 
--Guido van Rossum (python.org/~guido)
___
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/BIORRO5EXB65QWMYIIBCHHMWQR2ZRIC6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] PQM?

[Guido van Rossum]

On Wed, Aug 13, 2008 at 6:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Barry Warsaw wrote:
>>
>> PQM = Patch Queue Manager
>>
>> Basically, it's a robot that controls commits to the trunk.  Nothing lands
>> in the trunk without getting through PQM first.  PQM serializes changesets
>> so that they must apply cleanly with no conflicts, and pass the entire test
>> suite.  There could be other conditions, e.g. that it lints cleanly, has no
>> whitespace issues, etc.
>
> Personally I'm totally against any kind of tool like PQM for general
> development. Issues due erroneous check-ins are a social problem. I strongly
> believe that social problems can't be solved by a system like PQM. PQM may
> work for companies or projects with a large developer group but not for
> Python.
> I fear it'd cause more problems than it's worth. There are valid reasons for
> checking in failing unit tests. For example a developer spots a problem but
> isn't able to fix on his own. Any fancy system that delays or prohibits
> check-ins is going to slow us down.
>
> In my opinion a system like PQM should only be used when a RC or final
> release is immanent. I can picture the usefulness of PQM during the last few
> weeks before a release.
>
> I'd rather see the man power put into better testing facilities than into a
> tool like PQM. If you are worried about the stability of the trunk I'd
> rather suggest a change of our code of conduct. For example every change of
> code, which isn't just a minor change, must be applied to a new branch and
> reviewed by a second developer before it's applied to the trunk. I think
> development inside branches and peer reviewing yield better results than a
> machine that rules over developers.
>
> Christian, who still thinks (hopes) that the human mind outperforms machines
> when it comes down to important and complex decisions.

[Hey Christian, welcome back! (It seems we hadn't heard much from you
for a while...)]

I don't have experience with PQM or something like it, but I suspect
it doesn't scale, and the buildbots are a better approach, because
they handle multiple platforms.

I do think that better tools can help us some -- while you can't solve
every social problem with tools, the reverse isn't true either --
sometimes it *is* possible to solve (or at least alleviate) social
problems with tools.

As long as we're touting tools or processes that we have experience
with, Google uses a combination of tools. One tool is similar to the
buildbots, running tests *after* stuff has been checked in. A feature
that buildbot is missing is that it tries to figure which checkin is
responsible for a particular failure, and mails both the author of
that change and the owner of the code (if different).

Another tool that helps code quality tremendously is mandatory peer
reviews of all code before checkin. Call me biased because I wrote the
first version of the tool that most Googlers today use for peer
reviews (Collin Winter now runs that show) and also open-sourced a
similar tool (Rietveld, http://codereview.appspot.com) that works with
Subversion. But I didn't set the policy of mandatory pre-checkin peer
reviews -- Google had that policy for years before, and other tools
had already been written.

I particularly like the peer review policy because it is actually
largely a *social* solution: code review is a very social process, the
tools are secondary. By peer-reviewing all code before it goes in, not
only do you catch many problems in an earlier stage than otherwise
possible, but it also ensures that there are always at least two
developers who know and understand the changes (or new code --
everything gets reviewed, even doc changes and changes to build
files). Plus, it improves relationships between developers: if
yesterday I found a bug in your code during peer review, today I may
be more susceptible to you pointing out bugs in *my* code. This is a
lot better than finding bugs during debugging sessions: once you've
spent an hour tracking down a nasty bug you're much more likely to
have a low opinion of whoever checked in the buggy code, and you're
less likely to trust their judgment of your own code.

Anyway, if we're going to change policies around submitting code, I
would much rather see peer review become a habit than adopt a tool
like PQM.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Trunk and 3.0 branch are now open

[Guido van Rossum]

[Brett]
>> Since the next step is release candidates, I have two questions:
>>
>> 1. Do commits now require a code review?

[Barry]
> Ideally, all comments are reviewed , but I think the current
> arrangement will have to work for the rc's.  I'd say be even more careful
> about the changes you introduce in behavior or API.

I think it makes sense now to require review by another committer for
*all* changes until the final release, even trivial fixes of obvious
bugs, with the exception of doc fixes. This would also allow touching
up docstrings and comments without review. To enforce this, how about
the requirement of adding "Reviewed by " to the checkin
comment?

[Brett]
>> 2. Should we make release blockers out of anything we think must be
>> fixed before final?

[Barry]
> Yes.

Right. This means that anything that's not a release blocker should be
considered okay to leave unfixed. There are enough release blockers
left that we'll have our hands full fixing just those.

We need to start triaging bugs with the goal of a rock solid release
-- many bugs found at this point (or long known) are better left
unfixed rather than destabilizing the release. There is no exact
science to this, no hard and fast set of rules -- but before deciding
to fix a bug, please consult at least one other committer, and when it
doubt, mail the list. It's much better to leave some bugs unfixed than
to stumble badly in the rush towards one more fix.

As for anything that smells like a feature, Just Say No!

And finally: merges from the trunk to 3.0 should be done *very*
carefully. I request that whoever does a merge runs the full test
suite (with --uall) before committing.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Fwd: Trunk and 3.0 branch are now open

[Guido van Rossum]

Hm, I can't say how the "needs review" query works...

On Thu, Aug 21, 2008 at 12:00 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> -- Forwarded message --
> From: Benjamin Peterson <[EMAIL PROTECTED]>
> Date: Thu, Aug 21, 2008 at 1:58 PM
> Subject: Re: [python-committers] Trunk and 3.0 branch are now open
> To: Brett Cannon <[EMAIL PROTECTED]>
>
>
> On Thu, Aug 21, 2008 at 1:30 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>
>> That's what I was thinking; either real name or username, which ever
>> you remember at the time. Since we don't have a way to flag an issue
>> with a patch as needing a committer review, either we just continually
>> check for release blockers with patches or we email here saying what
>> issues have a patch ready and just need a second review.
>
> I've created a keyword, "needs review", that we can attach to issues.
> Then you use the "Needs review" query [1] to find them.
>
> [1] 
> http://bugs.python.org/issue?%40search_text=&title=&%40columns=title&id=&%40columns=id&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=8&priority=&status=1&%40columns=status&resolution=&%40group=&%40pagesize=50&%40startwith=0&%40sortdir=on&%40queryname=Needs+review&%40old-queryname=&%40action=search
>>
>> -Brett
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> http://mail.python.org/mailman/listinfo/python-committers
>>
>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Cutting Python 2.6

[Guido van Rossum]

On Wed, Oct 1, 2008 at 12:36 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Over the next several hours I will be cutting Python 2.6.  All lights and
> buildbots are go for final release tonight.
>
> I have not yet heard from Trent about press releases, so we'll have to do
> those after the fact.

Press releases can lag behind, but I hope that this time the Windows
and OSX installers will be released together with the main tarball.

> I am also planning on releasing 3.0rc2 tonight, but only if there's time.

I'd recommend against this now. We need a few more days to implement
the solution for undecodable filenames. There's a patch set by Victor
Stinner that does most of what I'd like to have, but it needs 1-2 more
rounds of review and refinements. I'd really like to hold up rc2 until
this is in.

>  Final releases have much more work and the process is much less tested, so
> it may take me quite a while to get 2.6 final out.
>
> The trunk and 3.0 branches are officially frozen until further notice.  You
> /must/ contact me on irc if you need to make any changes.

Why freeze the 3.0 branch?

> Remember: #python-dev on irc.freenode.net.  Please include my nick 'barry'
> in any ping so I will notice.
>
> Yee haw!

Amen! Thanks for your relentless efforts, Barry and others!!!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Cutting Python 2.6

[Guido van Rossum]

There should be a way to re-tag only the file(s) that contain the fix.

On Wed, Oct 1, 2008 at 4:00 PM, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> If there's a screwup, and you need to recut the branch, you want to be
> sure someone else hasn't been helpful and added something else to the
> repo.
>
>
> On Thu, Oct 2, 2008 at 9:37 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Barry Warsaw wrote:
>>> IIUC, the critical bottleneck is tagging the tree, so the RM needs to
>>> make it far enough through the PEP to get to that point.  Of course that
>>> does mean freezing the tree, and I don't think it's too difficult to do
>>> that.
>>
>> I always found strange the need to freeze the tree. When a svn tag is
>> created, the build process should use that tag to extract the files and
>> build the release, while the repository is being updated normally.
>>
>> In fact in a *.0 release, the tag should be a branch actually.
>>
>> Sure I'm missing something...
>>
>> - --
>> Jesus Cea Avion _/_/  _/_/_/_/_/_/
>> [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
>> jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
>> .  _/_/  _/_/_/_/  _/_/  _/_/
>> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
>> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
>> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.8 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF
>> cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp
>> sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG
>> SNs5cVMhe7g=
>> =VRp9
>> -END PGP SIGNATURE-
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> http://mail.python.org/mailman/listinfo/python-committers
>>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.0rc2 schedule

[Guido van Rossum]

On Thu, Oct 2, 2008 at 9:36 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Oct 2, 2008, at 12:31 PM, Raymond Hettinger wrote:
>
>>> IMHO if there's still big scary stuff out there, calling this a
>>> release candidate does us no good PR-wise, and does no good for our
>>> users. 3.0 is going to be scary enough for them as it is - cutting a
>>> release candidate that we either know is broken, or else has
>>> significant changes, is a very bad idea.
>>
>> I concur.  Better to go through another beta.
>> It feels like 3.0 is being rushed.
>
> I agree.  I'm swamped right now, but I will try to put together a revised
> schedule proposal later tonight.
>
> Someone please distract Guido while I "borrow" the keys to the time machine.

No need to be sneaky about it, go right ahead. I don't think we should
retroactively rename rc1 to beta4, but we can certainly label the next
release as beta5, with an explanation, and the first real release
candidate should be called rc2 to avoid confusion.

BTW I'll go over the release blockers today and see what I can do.
We've got to get this baby back on the road! :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.0rc2 schedule

[Guido van Rossum]

On Thu, Oct 2, 2008 at 10:08 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
>>
>> If you don't make a habit of borking your own filesystems with dodgy
>> filenames, it runs fine.
>
> I really hope the individuals making this argument are being facetious.  I
> don't think this is the source of the problem at all.
>
> The expect the most common occurrence of the problem comes from sharing of
> drives between operating systems and individual configurations; those
> ubiquitous little USB "thumb" drives get shared between all kinds of
> computers these days as people share files they don't want to or can't pass
> over a network for whatever reason.  (Those drives might actually serve
> other purposes first, such as being music players, and so may have no other
> interfaces for transferring files.)
>
> If someone hands me a USB flash drive with filenames encoded in whatever is
> reasonable for them, I should be able to use Python tools on the files
> without having to use non-Python tools to copy or rename the file first.
>  The possibility of a conflicting encoding is increased if the source
> machine is configured to use a very different encoding, clearly, but that's
> not that unusual.
>
> The world is smaller than it used to be, and we really need to understand
> that.

All good points.

However no matter how you spin it, we're in a hard place. If we
maintain that filenames should always be represented as text strings,
we have no choice of coming up with a way of encoding all possible
byte sequences into Unicode strings, using a reversible encoding. This
has been shown to be hard no matter what encoding you favor -- as soon
as those "Unicode" strings are passed on to other libraries or
programs nobody is sure how they will be treated.

If we switch to the view that all filenames are bytes after all,
Windows loses, because because not all filenames are representable
that way (unless you deviate from the encoding that Windows has chosen
for you, which presents other problems). Also, it would be a *huge*
project, since filenames are so ubiquitous.

There are a number of ways out, but I don't think we'll be able to
come up with a solution without doing a lot of experimentation.
Therefore I believe the best thing to do is to release 3.0 with a
low-level solution that makes it possible to carry out those
experiments. I am hoping that Martin will check in his
sys.setfilesystemencoding() function, and am am working on Victor
Stinner's code for better supporting filenames-as-bytes (in addition
to, not instead of filenames-as-text), and I expect that these two are
together to allow the necessary experimentation to take place
post-3.0.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.0rc2 schedule

[Guido van Rossum]

I forgot one thing. In the *long* run I expect the problem to go away
-- UTF-8 is going to win out. But this is years off, and that's why we
need to support non-UTF-8-encoded filenames in the short and medium
term. And this can be many years.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.0rc2 schedule

[Guido van Rossum]

On Thu, Oct 2, 2008 at 11:11 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
> That doesn't mean it's not scary when thinking about writing portable code
> in this environment.  That's not entirely new, but the fact that so much of
> these details are being addressed so late in the release cycle *should* give
> cause for concern, especially to those of use who are still a long way from
> stepping up to current versions.

I had always expected that issues like these would crop up fairly late
in the Py3k development cycle -- the first two years were completely
filled with discussions about language changes, and then their
implementation. Library stuff (and this *is* library stuff, even if
it's pretty fundamental) necessarily had to come later, once we had a
more-or-less usable version of the language.

FWIW, I don't expect any of the other release blockers to be quite
this invasive -- and this one is actually not all that invasive, since
most system calls *already* supported bytes alongside with text
strings. There are only two C-level changes: the addition of getcwdb()
(and the removal of getcwdu()), and the change in behavior for
listdir() with a text string argument (skipping undecodable filenames
rather than returning raw bytes). There was a one-line change in io.py
to make the built-in open() function (which is really an alias for
io.open()) accept bytes, and then a bunch of changes to posixpath.py,
glob.py and fnmatch.py to support bytes.

It's really not very invasive, and not much changes -- the changes are
mostly in our minds, as we now have all learned about the issues and
the differences between platforms, and know what to tell people to do
about them. *That* is the major change, not the few code changes.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.0rc2 schedule

[Guido van Rossum]

On Thu, Oct 2, 2008 at 12:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I'm still in favor of a solution that doesn't divide the APIs into
> "character file names" and "byte file names"; I want the "character
> file names" to work always.

I wish we could do that too, but I don't see how to make it work in
all contexts. If you are passing filenames to other programs or
libraries you may be forced to pass bytes, or in other cases you may
be forced to give up on supporting undecodable filenames (e.g. when
passing filenames to something written in Java).

> However, I find it completely unrealistic
> to make this work in Python 3.0. Providing that feature in 3.1 is
> still early enough, plus it requires a PEP.

Right.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-3000] Proposed Python 3.0 schedule

[Guido van Rossum]

On Mon, Oct 6, 2008 at 5:47 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> So, we need to come up with a new release schedule for Python 3.0.  My
> suggestion:
>
> 15-Oct-2008 3.0 beta 4
> 05-Nov-2008 3.0 rc 2
> 19-Nov-2008 3.0 rc 3
> 03-Dec-2008 3.0 final
>
> Given what still needs to be done, is this a reasonable schedule?  Do we
> need two more betas?

I know I'm contradicting what I said earlier, but perhaps we should
just forget going back to beta and stick to ever-more-perfect release
candidates? In other worlds release candidates often contain tons of
imperfections (I believe I've seen this both for Java and Windows) and
the label "release candidate" more clearly encourages people to
download and play with it, which is what we need at this point! Then
the schedule would be something like

  15-Oct-2008 3.0 rc 2
  05-Nov-2008 3.0 rc 3
  19-Nov-2008 3.0 rc 4
  03-Dec-2008 3.0 final

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python 3.0 branches ready

[Guido van Rossum]

On Wed, Dec 3, 2008 at 9:31 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Le mercredi 03 décembre 2008 à 12:27 -0500, Barry Warsaw a écrit :
>> Also note that the py3k branch is now open for Python 3.1!  Have fun
>> and see you in 18 months.
>
> You're not disappearing for 18 months are you? :)

Hm, I might actually consider doing that... :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] Luke Kenneth

[Guido van Rossum]

Is anyone else frustrated by Luke Kenneth Casson Leighton's rants in
python-dev? It seems he is living on another planet to me. Or am I
seeing it all wrong?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Luke Kenneth

[Guido van Rossum]

On Sun, Jan 25, 2009 at 9:15 AM, Steve Holden  wrote:
> Guido van Rossum wrote:
>> Is anyone else frustrated by Luke Kenneth Casson Leighton's rants in
>> python-dev? It seems he is living on another planet to me. Or am I
>> seeing it all wrong?
>>
> He seems rather misguided, and is being treated with great tolerance. I
> believe many of his posts also appear on comp.lang.python (where they
> appear to be mostly ignored).
>
> He's aiming at a worthy goal, but appears to be climbing up the learning
> curve rather tediously.

He's been on the learning curve forever. I don't think he's actually
making progress.

Anyone who feels like biting his head off, go for it.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Luke Kenneth

[Guido van Rossum]

Luke's tracker access has now been revoked, and he's been told
multiple times by different people both publicly and privately that
he's not welcome. I've warned him that if he keeps going on we'll have
to invoke the Nazis.

I certainly don't expect that he'll stop right away, but the best
response in this case is none. Let's just delete his mail and
eventually he'll go away. It'll be difficult -- he's already trying to
make us feel guilty for not supporting free software enough. Arguing
with him is like getting involved with quicksand, so let's just all
ignore him, and it will tide over.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] build dependency on the branches on sphinx trunk necessary?

[Guido van Rossum]

I'm not sure I understand your request. Is it okay to build docs using
a version of sphinx that is included in the distro? Is there a
specific revision that you would like to see rolled back, or do you
have a specific fix in mind? I suspect few people here understand the
(apparently largely political) ins and outs of the rules that guard
inclusion into Debian -- I certainly don't, and I don't have the time
to become an expert in them. So rather than trying to explain the
rules to us, could you make a specific suggestion of something we
could *do* to fix your problem?

--Guido

On Sun, Jan 25, 2009 at 5:40 AM, Matthias Klose  wrote:
> Hi,
>
> the requirement to build the documentation using a sphinx version from the 
> trunk
> was merged to at least the 2.6 branch. This is clearly not a bug fix. Is it
> really necessary to rely on a trunk/unreleased version? Would it be possible 
> to
> revert this change?
>
> Background: The Debian distribution requires distribution of files which can 
> be
> edited in the preferred format, which excludes generated documentation. I can
> pre-build the 2.6 documentation, and then include it in the so called 
> "contrib"
> section of the archive, but I would like to see it available in the "main"
> section. Including a copy of the sphinx trunk in the python package uploaded 
> to
> the distribution would be a hack around this (it is unlikely that the sphinx
> trunk version will be available in Debian).
>
> For python-2.5, Debian was not able to put the docs in the "main" section,
> because a build tool with (in the eyes of Debian) "non-free" license was used 
> to
> build the docs. It is nice that this is fixed now, but for now one reason is
> exchanged by another one why we cannot move the docs to Debian's "main" 
> section
> of the archive.
>
>  Matthias
> ___________
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] build dependency on the branches on sphinx trunk necessary?

[Guido van Rossum]

On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose  wrote:
> Guido van Rossum schrieb:
>> I'm not sure I understand your request. Is it okay to build docs using
>> a version of sphinx that is included in the distro? Is there a
>> specific revision that you would like to see rolled back, or do you
>> have a specific fix in mind?
>
> the specific change was committed in r68428. I didn't check if reverting this
> causes regressions in building the docs.
>
> A safe approach would be to only use build dependencies on a branch which were
> released before the first release of the branch. I assume in this case, the
> branch should stick with sphinx-0.5 and not rely on newer sphinx versions (or
> sphinx dependencies which were released after the python-2.6.0 release).

This seems rather restrictive. It would mean that if we found a bug in
sphinx-0.5 that was fixed later in sphinx development we couldn't
depend on the bug being fixed for the lifetime of Python 2.6, to
satisfy this requirement. Ditto for new sphinx features that might
make life easier for the doc authors, or in some cases enable new
types of markup that would clarify the docs. It would make backporting
doc-fixes from 2.7 harder too.

I could live with "only depend on released versions of anything" but I
don't think I could live with "don't depend on anything released after
2.6.0 was released" (which IIUC is what you are proposing here).

>> I suspect few people here understand the
>> (apparently largely political) ins and outs of the rules that guard
>> inclusion into Debian -- I certainly don't, and I don't have the time
>> to become an expert in them. So rather than trying to explain the
>> rules to us, could you make a specific suggestion of something we
>> could *do* to fix your problem?
>
> please see the proposals above. I'm not sure about the best approach how to 
> make
> backporting to the branch as easy as possible.
>
>  Matthias
>
>> --Guido
>>
>> On Sun, Jan 25, 2009 at 5:40 AM, Matthias Klose  wrote:
>>> Hi,
>>>
>>> the requirement to build the documentation using a sphinx version from the 
>>> trunk
>>> was merged to at least the 2.6 branch. This is clearly not a bug fix. Is it
>>> really necessary to rely on a trunk/unreleased version? Would it be 
>>> possible to
>>> revert this change?
>>>
>>> Background: The Debian distribution requires distribution of files which 
>>> can be
>>> edited in the preferred format, which excludes generated documentation. I 
>>> can
>>> pre-build the 2.6 documentation, and then include it in the so called 
>>> "contrib"
>>> section of the archive, but I would like to see it available in the "main"
>>> section. Including a copy of the sphinx trunk in the python package 
>>> uploaded to
>>> the distribution would be a hack around this (it is unlikely that the sphinx
>>> trunk version will be available in Debian).
>>>
>>> For python-2.5, Debian was not able to put the docs in the "main" section,
>>> because a build tool with (in the eyes of Debian) "non-free" license was 
>>> used to
>>> build the docs. It is nice that this is fixed now, but for now one reason is
>>> exchanged by another one why we cannot move the docs to Debian's "main" 
>>> section
>>> of the archive.
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] build dependency on the branches on sphinx trunk necessary?

[Guido van Rossum]

On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose  wrote:
> Guido van Rossum schrieb:
>> On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose  wrote:
>>> Guido van Rossum schrieb:
>>>> I'm not sure I understand your request. Is it okay to build docs using
>>>> a version of sphinx that is included in the distro? Is there a
>>>> specific revision that you would like to see rolled back, or do you
>>>> have a specific fix in mind?
>>> the specific change was committed in r68428. I didn't check if reverting 
>>> this
>>> causes regressions in building the docs.
>>>
>>> A safe approach would be to only use build dependencies on a branch which 
>>> were
>>> released before the first release of the branch. I assume in this case, the
>>> branch should stick with sphinx-0.5 and not rely on newer sphinx versions 
>>> (or
>>> sphinx dependencies which were released after the python-2.6.0 release).
>>
>> This seems rather restrictive. It would mean that if we found a bug in
>> sphinx-0.5 that was fixed later in sphinx development we couldn't
>> depend on the bug being fixed for the lifetime of Python 2.6, to
>> satisfy this requirement. Ditto for new sphinx features that might
>> make life easier for the doc authors, or in some cases enable new
>> types of markup that would clarify the docs. It would make backporting
>> doc-fixes from 2.7 harder too.
>
> the rationale for this proposal is that when a Linux distribution does freeze
> for a release, only bug fixes are allowed during the freeze until the release.
> If you do consider a new release on the branch as a bug fix release which can 
> be
> allowed during a freeze, but it depends on a new upstream release of it's 
> build
> dependencies we still cannot include it because of the tightened build 
> dependency.
>
>> I could live with "only depend on released versions of anything" but I
>> don't think I could live with "don't depend on anything released after
>> 2.6.0 was released" (which IIUC is what you are proposing here).
>
> I could live with a "don't depend on anything released after 2.6.0 was 
> released,
> unless it is a bug fix release", e.g. allowing sphinx-0.5.x releases (assuming
> these don't have new features).
>
> I don't know of any other open source software which allows unlimited changes 
> on
> the build requirements in this way on a release branch.

I would agree with you if it was for stuff that matters to the runtime
environment. But IMO this strict requirement doesn't make sense for
documentation in micro-releases -- changes to the documentation don't
matter for the runtime backwards compatibility. AFAIK we also don't
block performance improvements in micro-releases (though you'd have to
ask a release manager for the exact policy).

Would it help if we started bundling the required version of sphinx with Python?

In general I expect that you're not going to get a lot of help with
this issue, since it sounds like typical "business as usual" in the
weird and wonderful world that is Debian politics, and we have limited
patience for that. We're all volunteers here too, and we're not really
looking for more work. If Debian wants to ship with an outdated
version of Python, it is free to do so.

--Guido

>  Matthias
>
>>>> I suspect few people here understand the
>>>> (apparently largely political) ins and outs of the rules that guard
>>>> inclusion into Debian -- I certainly don't, and I don't have the time
>>>> to become an expert in them. So rather than trying to explain the
>>>> rules to us, could you make a specific suggestion of something we
>>>> could *do* to fix your problem?
>>> please see the proposals above. I'm not sure about the best approach how to 
>>> make
>>> backporting to the branch as easy as possible.
>>>
>>>  Matthias
>>>
>>>> --Guido
>>>>
>>>> On Sun, Jan 25, 2009 at 5:40 AM, Matthias Klose  wrote:
>>>>> Hi,
>>>>>
>>>>> the requirement to build the documentation using a sphinx version from 
>>>>> the trunk
>>>>> was merged to at least the 2.6 branch. This is clearly not a bug fix. Is 
>>>>> it
>>>>> really necessary to rely on a trunk/unreleased version? Would it be 
>>>>> possible to
>>>>> revert this change?
>>>>>
>>>>> Background: The Debian distribution requires distribution of files which 
>&

Re: [python-committers] build dependency on the branches on sphinx trunk necessary?

[Guido van Rossum]

On Mon, Jan 26, 2009 at 2:26 PM, Matthias Klose  wrote:
> Guido van Rossum schrieb:
>> On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose  wrote:
>>> Guido van Rossum schrieb:
>>>> On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose  wrote:
>>>>> Guido van Rossum schrieb:
>>>>>> I'm not sure I understand your request. Is it okay to build docs using
>>>>>> a version of sphinx that is included in the distro? Is there a
>>>>>> specific revision that you would like to see rolled back, or do you
>>>>>> have a specific fix in mind?
>>>>> the specific change was committed in r68428. I didn't check if reverting 
>>>>> this
>>>>> causes regressions in building the docs.
>>>>>
>>>>> A safe approach would be to only use build dependencies on a branch which 
>>>>> were
>>>>> released before the first release of the branch. I assume in this case, 
>>>>> the
>>>>> branch should stick with sphinx-0.5 and not rely on newer sphinx versions 
>>>>> (or
>>>>> sphinx dependencies which were released after the python-2.6.0 release).
>>>> This seems rather restrictive. It would mean that if we found a bug in
>>>> sphinx-0.5 that was fixed later in sphinx development we couldn't
>>>> depend on the bug being fixed for the lifetime of Python 2.6, to
>>>> satisfy this requirement. Ditto for new sphinx features that might
>>>> make life easier for the doc authors, or in some cases enable new
>>>> types of markup that would clarify the docs. It would make backporting
>>>> doc-fixes from 2.7 harder too.
>>> the rationale for this proposal is that when a Linux distribution does 
>>> freeze
>>> for a release, only bug fixes are allowed during the freeze until the 
>>> release.
>>> If you do consider a new release on the branch as a bug fix release which 
>>> can be
>>> allowed during a freeze, but it depends on a new upstream release of it's 
>>> build
>>> dependencies we still cannot include it because of the tightened build 
>>> dependency.
>>>
>>>> I could live with "only depend on released versions of anything" but I
>>>> don't think I could live with "don't depend on anything released after
>>>> 2.6.0 was released" (which IIUC is what you are proposing here).
>>> I could live with a "don't depend on anything released after 2.6.0 was 
>>> released,
>>> unless it is a bug fix release", e.g. allowing sphinx-0.5.x releases 
>>> (assuming
>>> these don't have new features).
>>>
>>> I don't know of any other open source software which allows unlimited 
>>> changes on
>>> the build requirements in this way on a release branch.
>>
>> I would agree with you if it was for stuff that matters to the runtime
>> environment. But IMO this strict requirement doesn't make sense for
>> documentation in micro-releases -- changes to the documentation don't
>> matter for the runtime backwards compatibility. AFAIK we also don't
>> block performance improvements in micro-releases (though you'd have to
>> ask a release manager for the exact policy).
>>
>> Would it help if we started bundling the required version of sphinx with 
>> Python?
>
> yes, it definitely would help, including the dependencies needed by sphinx.

Let's see if Georg has any comments on that.

>> In general I expect that you're not going to get a lot of help with
>> this issue, since it sounds like typical "business as usual" in the
>> weird and wonderful world that is Debian politics, and we have limited
>> patience for that.
>
> you may call it politics, I call it reproducabilty of the build with a set of
> requirements. the limitation on "runtime backwards compatibility" could allow
> changes of the test environment as well, which might introduce noise in the
> testsuite, having to investigate about a regression in the runtime or the
> testsuite. I do see your point, but from the Debian point of view I do 
> disagree.

Too bad.

>> We're all volunteers here too, and we're not really
>> looking for more work. If Debian wants to ship with an outdated
>> version of Python, it is free to do so.
>
> your conclusion is wrong. Debian does want to ship with the most recent Python
> version released before a Debian freeze.

What conclusion? My use of "i

Re: [python-committers] Give Daniel Diniz Developer access on the tracker?

[Guido van Rossum]

Let's do it!

On Tue, Feb 10, 2009 at 11:01 AM, Brett Cannon  wrote:
> Daniel seems to be plowing through issues on the tracker and apparently
> Antoine has suggested he be added to the Developer role on the tracker. Any
> objections?



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Survey about DVCSs compared to svn

[Guido van Rossum]

On Fri, Feb 27, 2009 at 3:41 PM, Sean Reifschneider  wrote:
> But, I did want to say thanks to Brett for sticking his face in this fan.
> :-)  It's a task of practically religious-war-proportions, and obviously is
> something there are a lot of opinions and concerns over.  Thanks for
> working on this.

Thanks to Brett in deed.

Would it help if I made a pronouncement? Let me express my personal
feelings. Note that I can still be swayed many ways, so don't consider
this a pronouncement, but perhaps it can serve as a catalyst for the
decision making process.

- Mercurial: IMO we can't go wrong with this. I've tried it a bit for
small projects, and it's very easy to learn for a SVN user. I've
talked to Bryan O'Sullivan, and I'm impressed by the customer list,
which includes Mozilla and Sun.

-  Bazaar: Probably okay, but I'm lukewarm about it. It is also
apparently still slower than Hg. It is married to Launchpad whose UI
continues to confuse and frustrate me (e.g. why is the "report a bug"
link so much more prominent on the overview page than the "download"
link?). I also am a little worried that Canonical is a little too
eager to get us as a "high profile customer". The good news is that
Bzr and Hg are so compatible that Bzr fans will be able to use Bzr
even if the master repository (probably on Benjamin's hard drive :-)
uses Hg.

- Keeping Subversion: This would sadden me, because merging really
sucks, even with the 1.5 merge tracking feature.

- Git: Too complex, and I've heard that a negative attitude prevails
in the Git  community.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Survey about DVCSs compared to svn

[Guido van Rossum]

On Sat, Feb 28, 2009 at 1:35 AM, "Martin v. Löwis"  wrote:
> Fredrik Lundh wrote:
>> Btw, one of my concerns is that a move away from Svn breaks the process
>> for people who pull sources from Svn to build their own Pythons. I know
>> a few teams that do that, and switching to another system isn't just an
>> apt-get away for them. Do we have enough log info to be able to
>> determine how common it is that people pull down source kits using Svn?
>
> With the limitation that svn urls are difficult to process, see
>
> http://svn.python.org/webstats/
>
> The actual logs themselves roll over after four days.

What on earth happened between May and June 2008? The number of
"visits" went down dramatically (at least 3x), and stayed at that
level ever since.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Data corruption issue (C IO library)

[Guido van Rossum]

On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandl wrote:
> Antoine Pitrou schrieb:
>> Hello,
>>
>> A data corruption issue has been discovered in the C IO lib in Python
>> 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder
>> whether we should make a release quickly to minimize the probability of
>> users hitting the problem?
>> (Georg tells me Benjamin is on holiday, however)
>
> FWIW, I also think we should make a new micro release right now.  We can't
> be seen to take data corruption issues with the most basic file operations
> lightly, especially in Python 3; otherwise, people will think we still don't
> consider it ready for use.
>
> We can either make a release with only that patch applied, or a release of
> the full 3.1-maint branch, but the latter would need alphas and betas.

+1

> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Data corruption issue (C IO library)

[Guido van Rossum]

On Thu, Aug 6, 2009 at 5:42 PM, Brett Cannon wrote:
>
>
> On Thu, Aug 6, 2009 at 16:42, Guido van Rossum  wrote:
>>
>> On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandl wrote:
>> > Antoine Pitrou schrieb:
>> >> Hello,
>> >>
>> >> A data corruption issue has been discovered in the C IO lib in Python
>> >> 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I
>> >> wonder
>> >> whether we should make a release quickly to minimize the probability of
>> >> users hitting the problem?
>> >> (Georg tells me Benjamin is on holiday, however)
>> >
>> > FWIW, I also think we should make a new micro release right now.  We
>> > can't
>> > be seen to take data corruption issues with the most basic file
>> > operations
>> > lightly, especially in Python 3; otherwise, people will think we still
>> > don't
>> > consider it ready for use.
>> >
>> > We can either make a release with only that patch applied, or a release
>> > of
>> > the full 3.1-maint branch, but the latter would need alphas and betas.
>>
>> +1
>
> Is that for the former or latter solution? Assuming the former, who is going
> to organize this since Benjamin is on vacation? And do we want just a source
> release or a full binary release (I assume the latter but the former is a
> lot easier)?

I just meant to +1 the "we need to make a new micro-release right now"
paragraph. Logistically, I think it needs to be a full binary release
but it could be identical to 3.1 except for the one patch. Hopefully
that obviates the need for alphas and betas. Who? Not me :-(

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?

[Guido van Rossum]

On Tue, Oct 13, 2009 at 10:45 AM, Barry Warsaw  wrote:
> On Oct 13, 2009, at 1:41 PM, R. David Murray wrote:
>
>> I always thought that the idea of a release candidate was that if there
>> were any fixes _at all_ that there would be a new rc.  Only when no
>> bugs needing fixed are found does the rc turn into the actual release.
>> But I understand that this is an idealized rc/release policy :)
>
> I'll invoke the Umbrella Rule now.  If we don't do one we'll wish we had.
>  If we do, we won't have needed it.

Traceback (most recent call last):
  File "umbrella_rules.py", line 6, in 
UmbrellaRule()
  File "unbrella_rules.py", line 4, in UmbrellaRule
raise 
DuplicateRuleName('http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules-in-general/')
DuplicateRuleName:
http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules-in-general/

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit access for David Malcolm

[Guido van Rossum]

On Sat, Feb 20, 2010 at 12:39 PM, Benjamin Peterson  wrote:
> 2010/2/20 Jeffrey Yasskin :
>> David Malcolm is the Fedora maintainer for the Python package and has
>> written a gdb plugin to replace and dramatically improve our old
>> Misc/gdbinit file using the new python scripting support in gdb-7. You
>> can see it in action at
>> http://fedoraproject.org/wiki/Features/EasierPythonDebugging#User_Experience.
>> I'd like to get this into our repository asap, but he's also going to
>> be improving it fairly quickly. So it'd be nice if he could commit his
>> improvements directly.
>>
>> Do you guys think we should give him commit access so he can make gdb
>> and packaging-related changes?
>
> While I'm not opposed to this, perhaps the plugin should stabilize
> before it is added to the tree?

Assuming it's new optional functionality that doesn't affect the core
at all, I think we can let it in before it stabilizes.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Untabifying the C codebase

[Guido van Rossum]

On Tue, May 11, 2010 at 10:13 AM, Fred Drake  wrote:
> On Tue, May 11, 2010 at 9:25 AM, Barry Warsaw  wrote:
>> Who remembers the Great Renaming? :)
>
> Oooh!   Oooh!  I know that one!   :-)
>
>
>  -Fred

http://python-history.blogspot.com/2009/03/great-or-grand-renaming.html

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP checkin process

[Guido van Rossum]

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.

--Guido

On Wed, Jul 21, 2010 at 4:34 PM, Antoine Pitrou  wrote:
>
> Hello,
>
> Can a committer check-in their own PEP directly, or do they have to go
> through the p...@python.org process?
>
> Thank you
>
> Antoine.
>
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Eric Araujo (merwok) as Distutils commiter

[Guido van Rossum]

Well like it or not Tarek is not going to do it. So who will? You, or a new
volunteer?

--Guido (on Android)

On Jul 27, 2010 5:58 AM, "Antoine Pitrou"  wrote:
>
>> So long as Eric is prepared to commit to our standard procedures
>> (discussion and patches on issues before commit and general caution and
>> regard for backwards compatibility) I would like to see him given commit
>> rights under the watchful eye of Tarek and those who review checkins. We
>> could see this as an "experimental" commit access in line with the
>> lowered barrier proposed by Guido.
>
> I'm fine with commit access for Éric (especially for documentation
> issues where his contribution has been quite useful).
>
> The issue at hand is the fate of distutils maintenance.
>
> Regards
>
> Antoine.
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Eric Araujo (merwok) as Distutils commiter

[Guido van Rossum]

On Tue, Jul 27, 2010 at 3:24 PM, Antoine Pitrou  wrote:
> Le mardi 27 juillet 2010 à 07:15 -0700, Guido van Rossum a écrit :
>> Well like it or not Tarek is not going to do it. So who will? You, or
>> a new volunteer?
>
> Well, we don't even know if Éric actually volunteers for maintaining
> distutils.

I'm kind of guessing that Tarek checked with Éric first (as is
customary in such cases).

> Otherwise the module will just rot as Tarek said, until distutils2
> replaces it.

Well, rotting has been the distutils status quo for years, hasn't it?
In fact, I thought that once significant changes were made, things got
worse for a while due to (insanely subtle) backwards
incompatibilities.

> This is certainly a less than optimal transition, but if
> distutils2 matures quickly enough it will not be as painful as it seems.
> (much less painful anyway than the state of distutils before Tarek
> started maintenance on it)

Let's not forget that Tarek is also a volunteer. If he has to choose
between maintaining distutils or spending more time getting distutils2
in shape, the choice is his, but ISTM that the choice he stated (work
on distutils2) is the better one anyways.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Mercurial Status?

[Guido van Rossum]

On Wed, Aug 4, 2010 at 2:36 PM, Nick Coghlan  wrote:
> On Thu, Aug 5, 2010 at 12:41 AM, Jack Diederich  wrote:
>> On Sun, Aug 1, 2010 at 10:56 AM, Alexander Belopolsky
>>  wrote:
>>> On Sun, Aug 1, 2010 at 10:27 AM, Jesus Cea  wrote:
>>> ..
>>>> Good luck (and justice!) with your (both) thesis. Uhmmm, what is the
>>>> plural for thesis, in english?. In Spanish it is the same word, changing
>>>> the prefix article: "la tesis"/"las tesis" :).
>>>
>>> "theses"  - isn't English fun?
>>
>> I blame Greek.
>
> And Latin, and Germanic... and, well, pretty much every other language
> English speakers and their ancestors have ever encountered ;)
>
> I have a T-shirt which says "English doesn't borrow from other
> languages. It follows them down dark alleys, knocks them down and goes
> through their pockets for loose grammar". It's funny because it's true
> :)

LOL.

> Cheers,
> Nick.
>
> P.S. Other languages may be just as indiscriminate in their evolution,
> but English is the only one I know sufficiently well to comment on the
> way it evolves over time.

I think all languages borrow from other languages -- it's natural as
people travel and cultures commingle. In the current times, most
languages borrow constantly from English. In 30 years maybe we'll all
be borrowing from Chinese...

ObPython: Python has borrowed from many other programming languages;
early on, C was a dominant influence. Nowadays Java seems to be.
Python is also influencing other languages (e.g. Ruby, Scala,
JavaScript). Long live cultural diversity!

-- 
--Guido van Rossum (python.org/~guido)
___
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?

[Guido van Rossum]

Hm, tricky, the stdlib is already supposed to be ASCII only except for
author names in comments and a few specific encoding test cases. But
since your non-breaking space was in a comment you'd have to add
another exception to whatever checker exists.

How about fixing your personal tool chain so it displays non-breaking
spaces in an obviously different way?

On Sun, Nov 7, 2010 at 7:52 AM, Victor Stinner
 wrote:
> 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 :-)
>
> Victor
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] anyone still have access to the coverity scan results?

[Guido van Rossum]

If it is determined that nobody has access any more I can ping one of
my contacts at Coverity.

On Tue, Jan 18, 2011 at 4:52 PM, Brett Cannon  wrote:
> Access to the Python results is currently down, but has anyone
> actually accessed the Coverity scan results any time recently? Or who
> even has access anymore?
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] anyone still have access to the coverity scan results?

[Guido van Rossum]

I guess we'd also have to point them to the Hg servers (once we are
using Hg -- but that's a rant for a different day :-). I've pinged my
direct contact there to get in touch with whoever's in charge of
scanning open source projects.

On Tue, Jan 18, 2011 at 7:12 PM, Brett Cannon  wrote:
> Might have you ping them regardless because I am willing to bet that
> they never moved over to py3k and are still scanning trunk (if they
> are scanning at all). But obviously wait until we know if someone does
> have access and exactly what they are scanning.
>
> On Tue, Jan 18, 2011 at 18:54, Guido van Rossum  wrote:
>> If it is determined that nobody has access any more I can ping one of
>> my contacts at Coverity.
>>
>> On Tue, Jan 18, 2011 at 4:52 PM, Brett Cannon  wrote:
>>> Access to the Python results is currently down, but has anyone
>>> actually accessed the Coverity scan results any time recently? Or who
>>> even has access anymore?
>>> ___
>>> python-committers mailing list
>>> python-committers@python.org
>>> http://mail.python.org/mailman/listinfo/python-committers
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] anyone still have access to the coverity scan results?

[Guido van Rossum]

My coverity contact wrote back:

"""
Sure, the main contact is David Maxwell and he's reachable via
s...@coverity.com though if that doesn't work you can always just try
dmaxw...@coverity.com - they can give you access and update ...
whatever - he also is more up to date on where we are in moving the
open source
projects over to our new version (there's a pretty time consuming migration
involved among all the projects).  Maybe he can set up Python 3 directly on
the new version - I'm not really sure how they are handling all that...
"""

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Quick survey for PyCon talk on core development

[Guido van Rossum]

Actually you should post it to the python-dev IRC group.

2011/2/24 Łukasz Langa :
> Wiadomość napisana przez Brett Cannon w dniu 2011-02-24, o godz. 19:47:
>
> Just so people know, I took the survey and it actually only take a couple of
> minutes, not even a few.
>
>
> Exactly, and it's fun.
> Brian, you might consider tweeting about it. Then again, you might get some
> false positives ;-)
> --
> Best regards,
> Łukasz Langa
> tel. +48 791 080 144
> WWW http://lukasz.langa.pl/
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] SVN repository is now read-only

[Guido van Rossum]

On Fri, Mar 4, 2011 at 12:15 PM, Raymond Hettinger
 wrote:
>
> On Mar 4, 2011, at 8:55 AM, Georg Brandl wrote:
>
>> Antoine and me are starting the conversion now (it takes quite
>> a while to get the SVN repo and convert it, so we're doing it
>> overnight).
>
> Thanks for stepping up and getting this done.

+1

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [PSF-Members] [Fwd: Re: Push rights for Ross Lagerwall]

[Guido van Rossum]

On Wed, Mar 9, 2011 at 7:42 AM, Antoine Pitrou  wrote:
>
>> > No, sorry, that doesn't parse.
>> > We don't need an explanation, we need a *solution*. Nobody cares about
>> > explanations when most online projects accept patches and enrole
>> > committers freely.
>>
>> While I agree with you that we need to do this better; don't interpret
>> what "other projects do" as "doing it right".
>
> They definitely do it right from a social perspective.

Another way of doing it right from a social perspective is to give
someone commit privileges even while they are still figuring out how
to send in their agreement via snail mail. It is enough for the pile
of agreements to be eventually consistent. Assuming you all trust the
new committer, there is no need for a transaction where the receipt of
the agreement must have  occurred before they can be given access to
the system -- as long as it's indicated that it can be withdrawn if
they don't send in the agreement.

In the mean time, yes, we need a web-based way of submitting
agreements. I believe I have already mentioned once before that Google
has a simple web form for individual contributors
(http://code.google.com/legal/individual-cla-v1.0.html) and only
requires a faxed signature for corporate contributors (where there are
actual lawyers on the contributing side).

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [PSF-Members] [Fwd: Re: Push rights for Ross Lagerwall]

[Guido van Rossum]

On Wed, Mar 9, 2011 at 8:35 AM, Antoine Pitrou  wrote:
>
> Hello Steve,
>
>> > I don't care and don't want to argue (I insist about this) about
>> > religions, be it christianism or intellectual property.
>> > If you think a legal rule is needed, please just *ensure it doesn't get
>> > in the way*. That's your job as a self-proclaimed "protector of IP
>> > rights", not mine.
>> >
>> As I have already pointed out in this thread, the PSF is not a
>> "self-proclaimed" anything. It was established by Guido precisely to
>> ensure that the IP was unencumbered. So Guido clearly thinks the rule
>> is needed.
>
> I would like to hear Guido's opinion today about this. Python's
> development is not the same as it was 10 years ago, and the world has
> changed too.

If anything, we need the forms more than 10 years ago. BUT unlike then
it's acceptable to fill out a web form.

>> I think Jesse has pointed us to some very satisfactory potential
>> solutions. I also think you are making a mountain out of a molehill.
>
> The reason I am making a mountain out of a slightly oversized molehill
> is that otherwise it seems people here don't care to solve the issue,
> and instead keep patronizing about how the current process is fine
> (which it is!... as long as it isn't actually applied...).
>
>> Electronic forms are easier to deal with, but I seriously doubt their
>> absence has lost as much development effort as the total collective
>> developer time already expended on this thread :-)
>
> Well, I agree that not so much development effort has been lost because
> of us checking contributor agreements, but I think there's a reason, and
> you might not like it.

TBH I don't think that the implementation of the web form ought to be
the PSF directors' job. However approval of this change in process and
of the exact legal text that people agree to on the web form is. One
of the developers or some other volunteer can do the implementation --
just don't make it live until the PSF's lawyer has approved the text.
(Though if it was me I'd just copy the Google forms, scratch out
Google, and write in Python in crayon.) Please do record which version
of the form is agreed to.

As a temporary solution for new contributors, if you trust them, give
them their permissions and ask them to fill the paperwork later (soon,
but not as a condition for the permissions).

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Guido van Rossum]

On Sun, Apr 3, 2011 at 11:51 AM, Raymond Hettinger
 wrote:
>
> On Apr 3, 2011, at 8:27 AM, Senthil Kumaran wrote:
>
>> On Sun, Apr 3, 2011 at 11:17 PM, Antoine Pitrou  wrote:
>>> I'd like to propose giving committer rights to Nadeem Vawda.
>>
>> +1 to this proposal. Please ensure that Nadeem Vawda is "interested" too.
>>
>
> ... and that he's interested in being a long-term contributor.
>
> We don't benefit from having a large number of people
> with rarely used commit rights or folks that check-in a
> bunch of code and then disappear.

OTOH I don't see much of a cost either to having folks with
rarely-used commit rights (I am one myself :-), and I do see a risk in
placing the bar for commit rights too high (I don't want the Python
committers to be "growing old together"). So I think that it's enough
to require that someone is interested (always assuming we trust them).

I don't know Nadeem or his work so I'd abstain on this specific vote,
but the number of +1 votes (and lack of counter-votes) from people I
trust is enough for me.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python 2.6.7rc2

[Guido van Rossum]

On Fri, May 20, 2011 at 2:37 PM, Barry Warsaw  wrote:
> I believe I've reconciled the Python 2.6 hg and svn branches.  I've committed
> the changes to 2.6svn and working on the null merges for the 2.6hg branch.
> I'll push the latter at some point soonish.  Anyway, this means that I will
> cut 2.6.7rc2 today -- and actually announce it!

I hope you did copy the SimpleHTTPServer.py security fix that I just
commented on in the tracker.

> In the future, if you are going to apply patches to Python 2.6, please do so
> in both the hg and svn branches, since all 2.6 releases will be done from
> svn.  If you're unsure or don't feel comfortable about doing that, please send
> me the diff and I'll apply it to 2.6svn.  Or create/mark a bug as release
> blocker on 2.6 and attach the patch.

I'm not very happy with this requirement to do parallel checkins in hg
and svn. IMO everyone except for the release managers should be able
to live in the happy illusion that we've migrated to hg completely.

Of course I'm fine with having very restrictive policies about
checkins to hg branches for old versions where the releases are done
from svn. The more restricted the better. But requiring individual
developers to maintain parallel svn and hg trees is going too far.

> Thanks.  I probably don't need to say, no commits to the 2.6svn branch for now
> please.

Happy releasing!

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python 2.6.7rc2

[Guido van Rossum]

On Fri, May 20, 2011 at 3:34 PM, Barry Warsaw  wrote:
> On May 21, 2011, at 12:19 AM, Martin v. Löwis wrote:
>
>>Am 20.05.2011 23:37, schrieb Barry Warsaw:
>>> I believe I've reconciled the Python 2.6 hg and svn branches.  I've 
>>> committed
>>> the changes to 2.6svn and working on the null merges for the 2.6hg branch.
>>> I'll push the latter at some point soonish.  Anyway, this means that I will
>>> cut 2.6.7rc2 today -- and actually announce it!
>>>
>>> In the future, if you are going to apply patches to Python 2.6, please do so
>>> in both the hg and svn branches, since all 2.6 releases will be done from
>>> svn.
>>
>>At the moment, this wouldn't be possible, since the svn is blocked from
>>accepting commit unless they come from you or me.
>>
>>It would be better, IMO, if there was a single developer who would
>>migrate changes to svn, or to have some semi-automatic procedure for
>>that.
>
> Yep.  It's rather a pain to determine what those changes are though if the
> best you can do is a recursive diff on the two trees.
>
> What do you think about my response to Guido, specifically: if you commit a
> change to 2.6hg, be sure there's a release blocker issue open on 2.6 so that I
> can easily find what needs to be cross-ported.

That still requires developers to remember.

Isn't there some invocation of hg log --branch that would give you a
list of changes on the branch?

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Guido van Rossum]

I sent Anatoly a note and suggested that we talk on Skype. We'll see what
happens.


On Wed, Nov 7, 2012 at 6:08 AM, R. David Murray wrote:

> On Wed, 07 Nov 2012 14:26:15 +0100,  wrote:
> > What can we do? Apart from the obligatory joke of nudging him gently
> > towards Ruby, I think calling his behavior out is a good idea. Cory
> > Doctorow also thinks that "many trolls are perfectly nice in real life
> > -- sometimes, just calling them on the phone and confronting them with
> > the human being at the other end of their attacks is enough to sober
> > them up" [3]. If that fails, banning him would show that we care about
> > the quality of communication and technical prowess is no excuse for
> > abusive behavior.
>
> As Brett pointed out, calling him on his behavior seems to meet with
> pretty much zero success as far as modifying his future behavior goes.
> The problem with banning him in general is that that has its own
> consequences (and as Brett pointed out, how exactly do we do that?).
> Banning him for specific actions (such as editing the Guidelines)
> seems sensible.  We basically booted him off the infrastructure mailing
> list (I don't remember if it was a formal ban or not) when he was being
> off-topic and annoying there.
>
> > All in all, is anyone of the opinion that losing him as a community
> > member is worse than keeping him around?
>
> If losing him was the only consequence this would be pretty much a
> no-brainer.  However, it is likely the consequences of a general ban
> would be more widespread than that (negative publicity, etc).
>
> --David
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Guido van Rossum]

On Wed, Nov 7, 2012 at 8:55 AM, Antoine Pitrou  wrote:

> [...]
> >
> > All in all, is anyone of the opinion that losing him as a community
> member
> > is worse than keeping him around?
>
> No.
>

It's pretty clear that he's not a net value to Python development. But
perhaps his attempts at contributing (no matter how clumsy) have value for
him? I imagine it must be pretty lonely being the only geek with deep
Python knowledge and interest in Minsk. I realize he's making it hard to be
compassionate. But I still think what sets him apart from the typical troll
is that he doesn't do it because he likes disagreement. He just lacks
social skills (English not being his first language may contribute here).
And yes, he doesn't seem to be learning from the feedback he gets.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Guido van Rossum]

>From his response to me he seems to be unaware that there is a problem...


On Wed, Nov 7, 2012 at 12:39 PM, Andrew Svetlov wrote:

> I've sent email to Anatoly in Russian describing current situation.
> CC'ed Eli Bendersky and Łukasz Langa as humans who understand Russian
> well enough to be witness for my words.
>
> I've call Anatoly to stop disruptive activities and concentrate on
> productive ones.
>
> I hope I has been benevolent enough as well as strong enough to send
> him the current state.
>
>
>
> On Wed, Nov 7, 2012 at 8:32 PM, Eli Bendersky  wrote:
> > On Wed, Nov 7, 2012 at 9:26 AM, Dirkjan Ochtman 
> wrote:
> >>
> >> On Wed, Nov 7, 2012 at 6:01 PM, Guido van Rossum 
> wrote:
> >> > imagine it must be pretty lonely being the only geek with deep Python
> >> > knowledge and interest in Minsk.
> >>
> >> I don't want to distract from your point, but I'm not sure the
> >> underlying assumption is warranted here. I happen to have met a few
> >> pretty good Python programmers from the Baltic states, one of whom
> >> told me about user groups he went to.
> >
> >
> > Dirkjan, Belarus is not a Baltic state ;-)
> > That said, I agree with Andrew that Anatoly is probably not the only
> > experienced Python programmer in that country.
> >
> > Eli
> >
> >
> >
> > ___
> > python-committers mailing list
> > python-committers@python.org
> > http://mail.python.org/mailman/listinfo/python-committers
> >
>
>
>
> --
> Thanks,
> Andrew Svetlov
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Guido van Rossum]

No, I never got on Skype with Anatoly. I did write a very frank email and
got the usual response. I don't think I am up to doing anything more about
him. He doesn't bother me that much, I ignore most of his threads. He is a
reviewer and committer on Rietveld and behaves better there.

--Guido

On Wednesday, December 26, 2012, Brian Curtin wrote:

> On Wed, Dec 26, 2012 at 8:09 AM, Ezio Melotti 
> >
> wrote:
> > That said, ISTM that the main problem is that the way he communicates is
> not
> > really effective and that results in an "energy drain" for other people.
> > This can be addressed on both the sides.
> > The community should ignore the tone of the messages or even the messages
> > themselves and most importantly avoid replies that convey the same
> negative
> > feelings.
>
> I've filtered his emails to the trash for almost two years now, but
> I'm not going to ignore that he's now discouraging my friends and
> colleagues from contribution. I already removed myself from the nosy
> list on a bunch of issues he created in the past, and the people who
> were willing to work with him are dropping off. I also will not ignore
> his tone about a GSoC contribution being useless.
>
> > People should be able to recognize when a discussion is not
> > constructive anymore and leave it, rather than wasting time just to
> prove a
> > point or to repeat themselves.  (Note that this apply to everyone, and
> not
> > to anatoly in particular).
> > Regarding the effectiveness of the communications there's certainty room
> for
> > improvement, but apparently the previous attempts to address the problem
> > were unsuccessful.  I'm willing to make an attempt myself, as I think I
> have
> > a quite clear idea of the problem.
>
> You're wasting your time if you think you will be the one to break
> through to him after several people have already talked to him.
> Apparently he even got on Skype with Guido about this. People would
> *pay* to have that chance. Anatoly got it for being a jerk and it
> changed nothing.
> ___
> python-committers mailing list
> python-committers@python.org 
> http://mail.python.org/mailman/listinfo/python-committers
>


-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PyCon US 2013 attendees

[Guido van Rossum]

I'll try to attend 1-2 days of sprints (and the rest of the
conference, of course, and the language summit if there is one).

On Mon, Feb 25, 2013 at 11:59 AM, Barry Warsaw  wrote:
> On Feb 25, 2013, at 02:46 PM, R. David Murray wrote:
>
>>I'll be there the whole time (summit through the end of the sprints).
>
> Me too.  Us hard-core old-timers gotta stick together.
>
> -Barry
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers



--
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PyCon US 2013 attendees

[Guido van Rossum]

On Mon, Feb 25, 2013 at 12:21 PM, Ned Deily  wrote:
>  Guido van Rossum  wrote:
>> I'll try to attend 1-2 days of sprints (and the rest of the
>> conference, of course, and the language summit if there is one).
>
> Is there uncertainty about having the language summit on Wednesday?
> Michael had sent out notices about it earlier, as usual.
>
> http://mail.python.org/pipermail/python-committers/2012-November/002231.html

No, I just didn't remember. I'll be there. (Are there any other
summits planned?)

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] I will NOT be leading the core sprint at PyCon US this year

[Guido van Rossum]

So we have nobody to lead the core sprint? Maybe we should change the
subject to "WANTED: core dev sprint leader for PyCon" ? Is this the
best list, or should it go to python-dev?

On Tue, Feb 26, 2013 at 7:53 AM, Nick Coghlan  wrote:
> On Tue, Feb 26, 2013 at 5:13 AM, Brett Cannon  wrote:
>> In case people were just assuming I was going to, I'm actually flying back
>> home on the 18th so I don't think it would be a good idea to make me the
>> sprint leader this year since I will only be around for the first half of
>> the day. If someone else wants to take it on then sign up python-dev at
>> https://us.pycon.org/2013/community/sprints/projects/ .
>
> Between packaging and various work related topics, I currently expect
> to be trying to talk to people about a dozen different projects during
> the sprints, so I won't be able to do it either (I've organised a core
> sprint at PyCon AU for the last couple of years). I'm sure I'll be
> around at various points to help, but I can't promise to be around
> consistently enough to lead it.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers



--
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PyCon US 2013 attendees

[Guido van Rossum]

If someone organizes a visit to the computer museum I *definitely*
would like to tag along. Despite working around the corner for 7 years
I've never been. My first computer was a Cray design, and soon I will
be computer history myself. :-)

On Tue, Feb 26, 2013 at 10:34 AM, Ned Deily  wrote:
> In article
> ,
>  Nick Coghlan  wrote:
>> In regards to the original topic of the thread, I'm in California for
>> 2 weeks, starting the Tuesday before the conference. I haven't made
>> any plans for the 4 days I have between the end of the sprints and
>> flying home yet :) (Although Brett had some interesting suggestions)
>
> For those who haven't been there already, a visit to the Computer
> History Museum in nearby Mountain View is definitely worth a few hours.
> It has an especially fine collection of Seymour Cray designs.  The
> building itself is a tiny bit of history: built as SGI building 20, it
> was the prototype for SGI buildings 40 through 43, which are now the
> heart of the Googleplex.
>
> http://www.computerhistory.org/
>
> --
>  Ned Deily,
>  n...@acm.org
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers



--
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit rights to Ethan Furman

[Guido van Rossum]

+1 on Ethan.

On Friday, May 3, 2013, Eli Bendersky wrote:

>
>
>
> On Fri, May 3, 2013 at 8:59 PM, Eli Bendersky 
> 
> > wrote:
>
>> Hello,
>>
>> I'd like to propose to grant Ethan Furman commit rights. He's authored
>> PEP 309,
>>
>
> s/309/409/ - sorry for the typo
>
>
>
>

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Guido van Rossum]

On Tue, May 28, 2013 at 3:00 PM, Terry Reedy  wrote:
> As I said on the issue and in response to Benjamin's question, I prefer to
> have it appear near the top of the directory listing even when other non
> 'test_xxx' files are added.

I don't think that's a strong enough reason to give the name a
non-alphabetic prefix. Please just use README.txt.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Guido van Rossum]

I think we have a zen rule about this: Special cases aren't special
enough to break the rules. (And I know what the next rule is, but I
don't think it applies here. :-)

On Tue, May 28, 2013 at 4:56 PM, Terry Reedy  wrote:
> On 5/28/2013 7:23 PM, Guido van Rossum wrote:
>>
>> On Tue, May 28, 2013 at 3:00 PM, Terry Reedy  wrote:
>>>
>>> As I said on the issue and in response to Benjamin's question, I prefer
>>> to
>>> have it appear near the top of the directory listing even when other non
>>> 'test_xxx' files are added.
>>
>> I don't think that's a strong enough reason to give the name a
>> non-alphabetic prefix. Please just use README.txt.
>>
> As I explained in response to Antoine on pydev, I do not like generic README
> and would prefer a more specific name beginning with 'A'; however, I will
> just delete the '@' in my next patch, which will fix the one buildbot
> breakage.
>
> Terry
>
>
> ___________
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers



-- 
--Guido van Rossum (python.org/~guido)
___
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

[Guido van Rossum]

On Sat, Jun 22, 2013 at 12:35 PM, Barry Warsaw  wrote:
> [1] Well, maybe penultimate, but I wouldn't mind seeing the Mercurial
> equivalent of a wrastlin' match between him and the BDFL. :)

You wouldn't see that this summer though -- I could just tackle him in
the office. :-)

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

Have you read the latest on the python-dev thread? Several other people are
now also complaining. The only thing that makes sense to me is nothing --
banning Anatoly now is just going to cause a PR disaster. Not responding at
all will most likely cause it to blow over (surely they will collectively
make fools of themselves, and Anatoly's post is the closest to trolling
from him yet). I'll add some pointers to the peps repo README file so we
can close that issue properly as well.


On Fri, Nov 29, 2013 at 9:45 AM, Eli Bendersky  wrote:

> Brett, +1 from me. But I suggest we wait for Guido to express his opinion
> before taking any action. In a recent private correspondence with Christian
> (and myself CCd) Guido expressed reluctance to act against Anatoly at this
> time.
>
> Eli
>
>
> On Fri, Nov 29, 2013 at 7:04 AM, Brett Cannon  wrote:
>
>> I just want to make sure others know that Georg has warned Anatoly that
>> if he continues to re-open a specific issue he will lose his tracker
>> privileges (http://bugs.python.org/issue19822#msg204696). I stand behind
>> his warning and will support anyone who enforces it. I would suggest that
>> if he does this to *any* other issue that he be warned that flipping
>> *any *fields after a core dev has made a decision and without discussing
>> it first will also lead to his loss of privileges.
>>
>> I would also like to point out his attitude is still horrible at times;
>> being accused of spreading "ill FUD policies in favor of creating [a]
>> collaborative environment" is not exactly polite (
>> http://bugs.python.org/issue19826#msg204693).
>>
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>>
>>
>


-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

On Fri, Nov 29, 2013 at 10:41 AM, Georg Brandl  wrote:

> Am 29.11.2013 19:22, schrieb Tim Peters:
> > I pretty much ignore Anatoly, and that works really well for me - try it
> ;-)
>
> It's a nice option, I agree -- but someone has to triage his issues, or
> they
> will rot in the tracker for eternity.
>

Plenty of issues do rot there, it doesn't bother me much. If you don't want
to triage Anatoly's issues, don't; maybe someone else (Mark Lawrence? :-)
will.

The key thing to understand here is that you can't win an argument with
Anatoly. You can only avoid *getting* into one.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

On Fri, Nov 29, 2013 at 10:48 AM, Brian Curtin  wrote:

> On Fri, Nov 29, 2013 at 12:22 PM, Tim Peters  wrote:
>
>> I pretty much ignore Anatoly, and that works really well for me - try it
>> ;-)
>
>
> I've filtered his emails to the trash for close to two years now so I'm
> only aware of him when issues like this come up. He doesn't get to come in
> here and act how he does, and openly say he's being disrespectful on
> purpose, and then say that he can't be nice if we don't make him happy.
>
> I doubt he would walk into a restaurant, complain about the process they
> used to create their menu, then complain when they don't make food the way
> he likes, then be mean to the waiters and waitresses because they're not
> seeing to it that he is comforted. If he did, they'd just call the police
> and he'd be escorted out.
>

This analogy feels flawed -- Python users who are unhappy with the
community's process for change can't just switch to Ruby, because they have
all this software that's already written in Python.

I'm still thinking about whether there's something we committers should do
besides staying calm and staying out of the discussion despite the
offensive criticism, but nothing comes to mind.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

On Fri, Nov 29, 2013 at 11:31 AM, Antoine Pitrou  wrote:

> On ven., 2013-11-29 at 10:56 -0800, Guido van Rossum wrote:
> > On Fri, Nov 29, 2013 at 10:41 AM, Georg Brandl 
> > wrote:
> > Am 29.11.2013 19:22, schrieb Tim Peters:
> > > I pretty much ignore Anatoly, and that works really well for
> > me - try it ;-)
> >
> >
> > It's a nice option, I agree -- but someone has to triage his
> > issues, or they
> > will rot in the tracker for eternity.
> >
> >
> > Plenty of issues do rot there, it doesn't bother me much. If you don't
> > want to triage Anatoly's issues, don't; maybe someone else (Mark
> > Lawrence? :-) will.
>
> The real problem with trolls in an open community is that there'll
> always be new people to fall in their traps. We may not pay attention
> anymore, but other people will.
>
> Here's a small recap:
>
> - Anatoly has repeatably hostile rhetorics towards core development and
> the contribution process
>
> - he refuses to abide by some of our (rather lax, IMHO) contribution
> rules (e.g. CLA)
>
> - he continuously veers into meta-discourse (complaining about the
> development process)
>
> - he always rehashes the same obsessions
>
> - he was warned about his behaviour and acknowledges that his
> interaction is not satisfactory
>
> - he nevertheless refuses to change his behaviour
>
> - his behaviour has spawned several distinct threads over the time here
> at python-committers, purely about him and nothing else (i.e. it's not a
> hidden systemic issue)
>
> - his behaviour has been going on for years
>

I would add to this list that he is a really bad communicator. His English
grammar is so random that I often can't figure out what he is saying (*),
and he is either extremely terse or extremely verbose.

If you can get a majority of the committers to vote to ban him we should do
it -- but that's a high bar (many committers probably don't care enough to
vote).

__
(*) The PEP process bug was an example -- I couldn't tell if he was asking
"what is the process" or suggesting "please add a pointer to a description
of the process to the peps repo README.txt" or trying to propose an
alternative process.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

Here's another idea. Ban him temporarily from the tracker and the lists(*)
and tell him that to be unbanned he has to talk to me, and to me only. I
will then negotiate a cool-off period and posting guidelines with him. If
he violate those he will automatically be banned permanently (or at least
for a year).

(*) Which lists? I'd say python-dev and python-idea -- are there any other
lists where he hangs out? Or perhaps all lists on mail python.org just so
he won't take his complaints to other lists.


On Fri, Nov 29, 2013 at 11:59 AM, Antoine Pitrou  wrote:

> On ven., 2013-11-29 at 11:40 -0800, Guido van Rossum wrote:
> >
> > If you can get a majority of the committers to vote to ban him we
> > should do it -- but that's a high bar (many committers probably don't
> > care enough to vote).
>
> Well, many are probably inactive enough to not even notice this
> discussion :-) I'm not sure about the authoritative source, but the SSH
> keys repository shows 178 people with access rights. The majority of
> them isn't probably active nowadays.
>
> Then I don't know where his behaviour is most problematic: on the
> tracker or the MLs?
> If we only ban him from the tracker, I'm afraid he'll start making
> "here's an issue I can't post on the tracker because I'm banned" posts
> on the mailing-list...
>
> Perhaps a temporary ban? There does need to be a signal sent to him.
> (apparently, he stopped reopening the issue when Georg told him
> reopening the issue would lead to loss of posting rights, which implies
> he is sensitive to this kind of signals)
>
> Regards
>
> Antoine.
>
>
> ___________
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

On Fri, Nov 29, 2013 at 11:34 AM, Brett Cannon  wrote:

>
>
>
> On Fri, Nov 29, 2013 at 1:56 PM, Guido van Rossum wrote:
>
>> On Fri, Nov 29, 2013 at 10:41 AM, Georg Brandl  wrote:
>>
>>> Am 29.11.2013 19:22, schrieb Tim Peters:
>>> > I pretty much ignore Anatoly, and that works really well for me - try
>>> it ;-)
>>>
>>> It's a nice option, I agree -- but someone has to triage his issues, or
>>> they
>>> will rot in the tracker for eternity.
>>>
>>
>> Plenty of issues do rot there, it doesn't bother me much. If you don't
>> want to triage Anatoly's issues, don't; maybe someone else (Mark Lawrence?
>> :-) will.
>>
>
> Maybe, but not the issues for stuff some of us are heavily invested in. If
> he starts to file importlib bugs I am going to triage them because I try to
> close all importlib bugs. I try to at least triage the ast issues as well
> which is where I have been bumping up against him as of late. The idea of
> having to change how I and others triage bugs because of one individual
> seems like the wrong cost/benefit ratio for dealing with the problem.
>

The question is, how effective will the alternative solution (banning him)
be? I worry that it's just going to make things worse.


>
>
>>
>> The key thing to understand here is that you can't win an argument with
>> Anatoly. You can only avoid *getting* into one.
>>
>
> I'm sure you have developed skills at ignoring people based on the amount
> of unsolicited communication sent your way as BDFL. But the rest of us
> really only have to put up with this consistently with a single individual.
> I know you're worried about some PR problem, but this isn't some knee jerk
> reaction but a multi-year issue that everyone has sustained. And this
> slowly leaks into everything because new people come, try to participate
> with him, and then get the negative consequences of that which becomes a
> low, simmering PR problem of its own that we are not more welcoming and
> tolerate rude individuals.
>

Do you have examples of new people engaging him? I mostly see him engaged
by old-timers or other known "difficult" users (Kristjan, Mark Lawrence).

I guess I haven't managed to teach you all well enough how to do this.
Honestly it's not easy. :-(


>
> If someone turns away from the community because we decided we didn't want
> someone who is rude participating and ruining the experience for others
> then I'm fine with losing that person's participation just like anyone who
> chooses not to come to PyCon because we have a CoC (they can still use
> Python, they can just choose to not participate in the community). But if
> we lose a single individual because they didn't like someone being rude to
> them or others then that is a loss I don't want to see. Once again, the
> cost/benefit ratio of everyone as a group having to ignore a single
> troublemaker does not seem like the best solution.
>

Again, I haven't seen Anatoly interfere with others. I imagine that most
people seeing his posts will recognize him as the nutcase he is.

>
> If you want to go with ignoring him, then that's fine. But to go along
> with that, I think it's reasonable to actively tell others who are new to
> not engage him if they start to in order to spare them the stress and
> aggravation and potentially losing their participation, otherwise how are
> they to know that this is not normal community behaviour and that he holds
> no sway? I do not want to continue to feel sorry for people who happen to
> reply to one person's emails knowing full well there was something I could
> do about it.
>

When I see this kind of thing happen to people who have already contributed
positively but haven't been around long enough to recognize specific trolls
I usually send them an off-line message suggesting to ignore the troll.
This happens a few times a year, and it's not just Anatoly.


-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

On Fri, Nov 29, 2013 at 1:16 PM, Ned Deily  wrote:
[bunch of stuff I agree with :-)]

> I think it would be hard to justify to the world banning Anatoly for his
> relatively minor annoyances when it took so long to do something about one
> help vampire whose behavior and the community's reaction severely damaged
> its atmosphere and really did scare new people away.
>

This led me to look up "help vampire" which led me to a wiki on the topic
of community management. Here's a sample link:
http://communitymgt.wikia.com/wiki/RTFM

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

Nick,

I think we've seen the issue from every possible side now. I trust your
judgment that he has pulled this trick once too many times. So please
implement the ban. Or wait until the next infraction -- that's up to you.
Either way, since the archives of this list are public, our deliberations
will stand up to scrutiny.

My offer to mediate (*after* he's been banned) stands, but it's up to you
if and how you want to mention that to Anatoly.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Guido van Rossum]

Nick,

Thanks for doing this emotionally grueling task.

--Guido

On Saturday, November 30, 2013, Nick Coghlan wrote:

> On 1 December 2013 01:49, Eli Bendersky >
> wrote:
> > On Fri, Nov 29, 2013 at 11:44 PM, Nick Coghlan 
> > >
> wrote:
> >> OK, moving on to mechanics, here's what I would like to propose:
> >>
> >> - flip his moderation bit on the mailing lists, at least for
> >> python-dev, python-ideas and distutils-sig (are there any other lists
> >> where his presence is considered disruptive?).
> >>
> >> - revoke his tracker privileges. If he would like something done on
> >> the tracker, he can ask Guido or Ezio to make the change on his
> >> behalf.
> >>
> >> I'm willing to be the bearer of bad news, and let Anatoly know this is
> >> being done, and cc' Guido and Ezio (as I'll also pass along their
> >> offers of assistance).
> >
> >
> > This plan sounds good. I agree with Alex that the initial email has to be
> > private. There's no need here for a public humiliation that will harm
> both
> > Anatoly and Python.
>
> OK, I've sent the notification to Anatoly. I cc'ed Guido and Ezio
> (since I included their offer to mediate tracker access) and also
> bcc'ed the list admins for the three currently affected lists (so they
> know why his posts start appearing in the moderation queue).
>
> I don't appear to have the necessary tracker access to actually move
> his account to read-only status, though (this change should be made on
> the meta-tracker as well).
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com|   Brisbane,
> Australia
>


-- 
--Guido van Rossum (on iPad)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Status of the Derby, and request for another slip

[Guido van Rossum]

On Sun, Jan 26, 2014 at 2:16 PM, Barry Warsaw  wrote:

> On Jan 26, 2014, at 01:59 PM, Eli Bendersky wrote:
>
> >This actually sounds like a real and interesting reason to have stable
> >Python 3.4 out in march. Ubuntu 14.04 is a LTS, which makes it an
> important
> >version for corporate distributions.
>
> Ubuntu 14.04 feature freeze is Feb 20, with beta 1 coming on Feb 27, so I
> think we have to make a hard decision about whether Python 3.4 will be the
> default before then (actually, Matthias and I will discuss it this week).
>
> If we go with 3.4 as default, then 14.04 final beta is March 27th.  Python
> 3.4's final release is currently schedule for March 16, but that doesn't
> include the proposed additional beta.  Pushing everything back a week means
> the schedule is quite tight, so we may have to plan on doing an SRU (stable
> release upgrade) to the final Python 3.4.  That's not ideal though because
> it
> means a lot of users may not get it (if they don't upgrade), and most
> probably
> won't see it until 14.04.1 is released some time later.
>
> The closer Python 3.4 can stick to the March 16th release, the better.
>

Yes. That's the whole point of time-based releases. Please stick to the
plan. We've already slipped once. Perfection is not required.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP 450: Commit access for Steven D'Aprano?

[Guido van Rossum]

+1


On Sat, Feb 1, 2014 at 5:02 PM, Nick Coghlan  wrote:

> When PEP 450 (the statistics module) was accepted, it looks like we
> missed the step of granting Steven commit access for module
> maintenance purposes. We should probably fix that :)
>
> I'm happy to handle the task of bringing Steven up to speed on the
> mechanics of contributing directly (and there's always the option of
> pinging core-mentors...@python.org with any specific questions).
>
> Steven: http://docs.python.org/devguide/coredev.html
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] review links

[Guido van Rossum]

IIRC the review link only appears if the patch applies cleanly.


On Mon, Feb 3, 2014 at 9:03 AM, Yury Selivanov wrote:

> Hello,
>
> Another quick infrastructure question (is this the right list, btw?):
> I don't see 'review' links for some patches. Like in issue #14911,
> Kristján uploaded two patches, same day, almost same time, and I
> see a review link only for one of them.
>
> Screenshot: http://goo.gl/HK2oer
>
> Thanks,
> Yury
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Brian Kearns for commit

[Guido van Rossum]

I have nothing against Brian personally, but I have a process question: Has
he previously gotten patches accepted to the stdlib, or is this a
preemptive request? I think the usual route is to grant commit access after
the stream of patches from a contributor has taken the form of a steady
stream (or at least trickle)
of high-quality patches, and the core committers are tired of committing on
that person's behalf and confident that the contributor will seek review
when appropriate.


On Mon, Mar 10, 2014 at 4:02 PM, Alex Gaynor  wrote:

> Hi all,
>
> I'd like to propose Brian Kearns for commit. He's been a committer on PyPy
> for about a year and a half now, and in particular he's done a bunch of
> "Python version" works: things like upgrading us from the 2.7.3 stdlib to
> the 2.7.6 stdlib, and py3k work. He's interested in having commit for the
> purposes of doing interop work on the stdlib tests: things like making sure
> tests aren't reliant on refcounting, correctly marking tests as impl
> details, etc.
>
> Thanks,
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.2.6, 3.3.6 planned for weekend

[Guido van Rossum]

Did the cookie fix get ported to these?
On Sep 30, 2014 5:50 AM, "Georg Brandl"  wrote:

> Hi all,
>
> I'm planning to tag 3.2 and 3.3 branch security releases on the weekend.
> No binary packages will need to be produced.
>
> Please let me know if there is any security-level fix you'd want to fit
> in before.
>
> 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] Proposed core developer for contributing to multiprocessing

[Guido van Rossum]

On Fri, Jan 9, 2015 at 2:52 PM, Antoine Pitrou  wrote:

>
> Le 09/01/2015 23:47, M.-A. Lemburg a écrit :
> >
> > Antoine and Victor argued that new developers should first
> > show their skills by submitting patches to tickets, working
> > with other core devs before getting the commit bit set.
> >
> > My suggestion was allowing new developers to start committing
> > patches themselves before having worked on dozens of tickets
> > using the usual patch approach.
>
> What would that bring? Reverting commits or asking people to make post
> hoc changes is much more bothersome than making pre-commit code reviews.
>
> And I don't see how it's beneficial to ask developers to commit up front
> while we're trying to promote a culture of code review, anyway.
>

I'm with Antoine here.

-- 
--Guido van Rossum (python.org/~guido)
___
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?

[Guido van Rossum]

Where I come from we always squash. More detailed history is preserved in
the code review tool (which keeps a snapshot every time you bounce it back
to the reviewer). Looking at my own sub-commits when I'm working on a
complex feature or bug fix, they are often checkpoints with no particular
significance except that the code is syntactically correct, and a common
reason for doing a sub-commit is when I've got to attend to something else
(e.g. a meeting).

On Thu, Apr 2, 2015 at 6:31 AM, Barry Warsaw  wrote:

> On Apr 02, 2015, at 12:06 PM, Jason R. Coombs wrote:
>
> >The way I see it, a squash of history or massive patch file loses
> history. It
> >loses details about the thought process of the implementer. It masks
> mistakes
> >and obscures motivations. It also masks decisions made in the merge
> >operation, further hiding potential problems.
>
> In general I agree.  Coming from bzr, it's very rare that merges get
> rebased
> first, but bzr has a strong "mainline-of-development" view that tends to
> make
> squash-before-merge unnecessary.  diffs, bisects, logs, etc generally
> follow
> first-parents by default so you don't see all the subcommits, unless you
> want
> to, which sometimes you do.
>
> git doesn't really follow this tradition (although some commands have an
> option to follow first parents).  Not sure about hg.
>
> Cheers,
> -Barry
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] "Gratuitous"? incompatibilities in the "fix only" releases

[Guido van Rossum]

I believe that in this particular case, the bug was fixed (by tightening
the requirements for headers) because the bug can lead to security
vulnerabilities. I think you can find more by Googling for keywords like
"http header injection". The more recent Python 2.7 bugfix releases have
specific exemptions from the backwards compatibility requirements for
security fixes -- because their lifespan will still be many years (EOL of
2.7 is summer 2020).

On Wed, Jul 29, 2015 at 6:06 PM, Jesus Cea  wrote:

> Yesterday I upgraded one of my computer to 2.7.10 and a program working
> for years failed.
>
> The problem is this:
>
> """
> http=httplib.HTTPConnection("127.0.0.1",8081)
> http.request("GET","/X/%f" %last_t, "", \
>   {"Authorization":"Basic %s" %base64.encodestring("%s:%s" %(a,b))})
> """
>
> base64.encodestring() creates base64 encoding with a final '\n'. This
> used to work until 2.7.9 but 2.7.10 if failing now with an exception
> about an "illegal character" in a header.
>
> I know that that code is faulty and I should drop the final '\n' or just
> use "base64.b64encode()" (my current fix). The point, thought, it that
> this code used to work in previous 2.7 releases but it is failing under
> 2.7.10.
>
> This incompatible change will be released in 3.4.4 too.
>
> I agree that new code is better, no argument here. My program was
> incorrect, sure. But I was under the impression that backwards
> incompatible code was forbidden in minor releases, except for very
> critical reasons (like the HTTPS security default backported to 2.7). I
> think that breaking working code during minor updates is risky and
> breaks user/programmer expectations.
>
> The change was done in <https://bugs.python.org/issue22928>.
>
> I think the change is the way to go, I don't ask for a revert (since
> 2.7.10 is already in the wild I want to keep it too in future 3.4.4) but
> I am interested in knowing the official statement of committers about
> backwards incompatible changes in minor releases for my own future
> reference.
>
> Sorry if this email seems confrontational. Not my intention, but my
> English is getting worse by the day :-). This is an inquiry about
> policy, not an attack.
>
> Thanks!
>
> --
> 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
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] "Gratuitous"? incompatibilities in the "fix only" releases

[Guido van Rossum]

When in doubt, such discussions should be escalated to python-dev. I don't
know if this one was, though I vaguely recall seeing it discussed
somewhere. Anyway, since it's been released, it should stay in.

On Wed, Jul 29, 2015 at 7:31 PM, Robert Collins 
wrote:

> On 30 July 2015 at 05:20, Eric Snow  wrote:
> >
> > On Jul 29, 2015 11:08 AM, "Robert Collins" 
> > wrote:
> >>
> >> On 30 July 2015 at 04:50, Guido van Rossum  wrote:
> >> > The more recent Python 2.7 bugfix releases have
> >> > specific exemptions from the backwards compatibility requirements for
> >> > security fixes -- because their lifespan will still be many years (EOL
> >> > of
> >> > 2.7 is summer 2020).
> >> [snip]
> >> https://docs.python.org/devguide/devcycle.html#security-branches
> >> "...The only changes made to a security branch are those fixing issues
> >> exploitable by attackers such as crashes, privilege escalation and,
> >> optionally, other issues such as denial of service attacks. Any other
> >> changes are not considered a security risk and thus not backported to
> >> a security branch."
> >>
> >> This page doesn't specify the exception for 2.7, and by my poor
> >> reading of it the http issue wouldn't pass muster - but I think it was
> >> appropriate to apply. So I'm confused. Help :).
> >
> > See PEP 466.
> >
> > https://www.python.org/dev/peps/pep-0466/
>
> Thanks - but that doesn't cover the 22928 fix as far as I can tell. It
> explicitly says in fact that its not carte blanch, and that things
> still need to be discussed
>
> and I'm still not clear where we should discuss them :)
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] How are we merging forward from the Bitbucket 3.5 repo?

[Guido van Rossum]

I presume the issue here is that Hg is so complicated that everyone knows a
different subset of the commands and semantics.

I personally don't know what the commands for cherry-picking a revision
would be.

I also don't know exactly what happens when you merge a PR using bitbucket.
(I'm only familiar with the GitHub PR flow, and I don't like its behavior,
which seems to always create an extra merge revision for what I consider as
logically a single commit.)

BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I
see (in a very big bold font) is "This is Python version 3.6.0 alpha 1".
What's going on here? It doesn't inspire confidence.

On Sun, Aug 16, 2015 at 10:13 AM, Larry Hastings  wrote:

>
>
> So far I've accepted two pull requests into bitbucket.com/larry/cpython350
> in the 3.5 branch, what will become 3.5.0rc2.  As usual, it's the
> contributor's responsibility to merge forward; if their checkin goes in to
> 3.5, it's their responsibility to also merge it into the
> hg.python.org/cpython 3.5 branch (which will be 3.5.1) and default branch
> (which right now is 3.6).
>
> But... what's the plan here?  I didn't outline anything specific, I just
> assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and
> merging.  But of the two pull requests so far accepted, one was merged this
> way, though it cherry-picked the revision (skipping the pull request merge
> revision Bitbucket created), and one was checked in to 3.5.1 directly (no
> merging).
>
> I suppose we can do whatever we like.  But it'd be helpful if we were
> consistent.  I can suggest three approaches:
>
>1. After your push request is merged, you cherry-pick your revision
>from bitbucket.com/larry/cpython350 into hg.python.org/cpython and
>merge.  After 3.5.0 final is released I do a big null merge from
>bitbucket.com/larry/cpython350 into hg.python.org/cpython.
>2. After your push request is merged, you manually check in a new
>equivalent revision into hg.python.org/cpython in the 3.5 branch.  No
>merging necessary because from Mercurial's perspective it's unrelated to
>the revision I accepted.  After 3.5.0 final is released I do a big null
>merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython.
>3. After your push request is merged, you pull from
>bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge
>into 3.5.  In this version I don't have to do a final null merge!
>
> I'd prefer 3; that's what we normally do, and that's what I was
> expecting.  So far people have done 1 and 2.
>
> Can we pick one approach and stick with it?  Pretty-please?
>
>
> */arry*
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Can't merge into 3.6 (default) branch

[Guido van Rossum]

I've made some changes to asyncio but I've run into a snag -- I can't merge
the changes from 3.5 into 3.6 (the default branch). It seems some other
changes to 3.5 haven't been merged and I don't want to just commit the
default merge outcome (which affected a huge number of files).

I thought the merge policy was to relentlessly merge everything from 3.5
into 3.6 (using null merges to mark decisions not to copy a specific diff)?

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Can't merge into 3.6 (default) branch

[Guido van Rossum]

Well, somehow I managed to fix it by switching directories... Not sure what
happened. :-(

On Mon, Sep 28, 2015 at 1:23 PM, Brett Cannon  wrote:

>
>
> On Mon, 28 Sep 2015 at 13:17 Guido van Rossum  wrote:
>
>> I've made some changes to asyncio but I've run into a snag -- I can't
>> merge the changes from 3.5 into 3.6 (the default branch). It seems some
>> other changes to 3.5 haven't been merged and I don't want to just commit
>> the default merge outcome (which affected a huge number of files).
>>
>> I thought the merge policy was to relentlessly merge everything from 3.5
>> into 3.6 (using null merges to mark decisions not to copy a specific diff)?
>>
>
> Yes, that is the merge policy, so someone messed up and didn't do the
> forward merge.
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Github accounts (was: formalising retirement as a Python committer)

[Guido van Rossum]

This hardly seems like a real problem, so let's not worry more about it
until someone actually needs help solving this.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] formalising retirement as a Python committer

[Guido van Rossum]

Andrew,

Thanks for your contributions. You will be missed. Enjoy your new pursuits
and interests! If you ever want to come back we'll make sure to accommodate
you somehow.

--Guido

On Sat, Jan 2, 2016 at 5:06 AM, Andrew MacIntyre <
andy...@bullseye.apana.org.au> wrote:

> Sadly I have come to the conclusion that there is no realistic prospect of
> my being able to actively contribute to Python development in the
> foreseeable future given my current pursuits and interests, though I rely
> heavily on Python both personally and professionally.
>
> As a practical matter I have not actively participated in Python
> development in some years and as a consequence I don't think I have any
> valid keys still on record.  Nor do I now have any operational OS/2 systems
> to support the Python port to that platform that was my primary interest
> and contribution.
>
> I would therefore request that appropriate administrative action be taken
> to close off any commit privileges previously granted to me that may still
> be active.
>
> Beyond the OS/2 port, it pleases me that I was able to make several small
> contributions of more general utility.
>
> While the announcement today of the planned move of the Python repository
> to GitHub has no bearing whatsoever on my decision, I would note that
> GitHub's requirement that a person only have one account - to be used for
> both personal activity and any activity on behalf of an employer - is of
> sufficient concern to me that had I decided to continue as a committer I
> would be seeking legal advice concerning my position. I say this as to date
> I have been able to satisfy my employer's requirements for clear separation
> of my personal activities, including my participation in Python
> development, from my activities as an employee.  This has been possible by
> exclusively using only provably personal resources, including accounts and
> internet access, for personal activities.  Such clear separation becomes
> much more difficult when resources such as accounts are shared between
> personal and employee roles, especially when being seen to do the right
> thing is as important as actually doing the right thing.
>
> My best wishes to all who have made Python what it is and for Python's
> future!
>
> Andrew MacIntyre.
>
> --
> -
> Andrew I MacIntyre "These thoughts are mine alone..."
> E-mail: andy...@bullseye.apana.org.au  (pref) | Snail: PO Box 370
> andy...@pcug.org.au (alt) |Belconnen ACT 2616
> Web:http://www.andymac.org/   |Australia
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

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

[Guido van Rossum]

Happy 2016 Brett! Thanks for all the care you've put into this decision. I
should also mention that I am happy that as a community we're always
willing to learn -- we've switched VCSes many times before and I expect we
will again in the future. Each time things get better, and I'm looking
forward to the implementation of this iteration, now that the decision is
made.

On Fri, Jan 1, 2016 at 9:31 PM, Ethan Furman  wrote:

> On 01/01/2016 11:24 AM, Brett Cannon wrote:
>
> Happy 2016 everyone, and here is to hoping we will have an easier
>> developer workflow by the end of this year!
>>
>
> Thanks for doing this, Brett!
>
> I'm looking forward to an easier work flow.
>
> --
> ~Ethan~
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Github accounts

[Guido van Rossum]

On Sun, Jan 3, 2016 at 5:38 AM, M.-A. Lemburg  wrote:

> On 03.01.2016 05:19, Guido van Rossum wrote:
> > This hardly seems like a real problem, so let's not worry more about it
> > until someone actually needs help solving this.
>
> For Andrew, it would have been a real problem, so IMO it's better
> to be prepared for it and let potential new contributors know that
> we can help resolve the issue.
>
> Otherwise, people who potentially have a problem wouldn't even
> consider contributing via the new Github workflow, which can't
> really be in our interest.
>

The problem can hardly be unique to Python, can it? Thousands of well-known
open source projects are now on GitHub. Also note Alex's comment that it
has literally never come up for Django (which IMO has a healthier ration of
contributors than core Python).

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

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

[Guido van Rossum]

On Mon, Jan 4, 2016 at 1:50 PM, Donald Stufft  wrote:

> I'm not sure that you'd see much savings. You'd only get deltas that were
> never merged to master excluded. Point taken though.
>

Is the expectation that a Git clone would be significantly larger than an
Hg clone of an equivalent repo? I currently often rely on a single Hg clone
containing all branches.

+1 on not supporting ESR, for the stated reason.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Deprecation Policy PEP

[Guido van Rossum]

Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11, etc.

I also want the 3->4 transition to feel like a non-event for most
users. How we'll do that I don't know yet, but I want it to be a lot
smoother than 2->3.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers