[python-committers] New triagers: Thomas Grainger and Michael Droettboom

[Christian Heimes]

Please welcome our newest triagers:

Thomas Grainger, who is the maintainer of anyio and has been fixing 
asyncio bugs in the past three years. 
https://github.com/python/core-workflow/issues/471


Michael Droettboom, who is the creator of Pyodide (Python in the 
browser) and has helped to unblock 3.11b release. 
https://github.com/python/core-workflow/issues/472


Regards,
Christian
___
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/NHBTHFFYOVPIIKJBMJJVAIN4C3ZWPOVB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Christian Heimes]

On 08/06/2022 21.21, Brett Cannon wrote:
FYI there are now tier labels for the buildbots and the links have been 
added to the PEP.


https://peps.python.org/pep-0011/#support-tiers 

Tier 2: 
https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-2 

Tier 3: 
https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-3 



(Tier 1 is covered by 
https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted 
 
.)


FYI, https://github.com/python/cpython/issues/93491 has landed. 
./configure now checks and reports support tier level:



checking for PEP 11 support tier... x86_64-pc-linux-gnu/gcc has tier 1 
(supported)



checking for PEP 11 support tier... wasm32-unknown-emscripten/clang is 
not supported

...
Platform "wasm32-unknown-emscripten" with compiler "clang" is not 
supported by CPython core team, see https://peps.python.org/pep-0011/ 
for more information.



Christian
___
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/X2G66FGT4WU6CI562FWFAP6ZZS23N4JU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

[Christian Heimes]

On 01/04/2022 01.40, Victor Stinner wrote:

Hi,

I don't think that the current PEP 11 draft (*) describes correctly
the current status of a bunch of platforms which are not "actively"
supported. I like to call these plaforms as "best effort support"
platforms. I propose considering adding an explicit "Tier 3" to PEP
11.

(*) https://github.com/python/peps/pull/2442/

Rust defines its Tier 3 as: "Tier 3 targets are those which the Rust
codebase has support for, but which the Rust project does not build or
test automatically, so they may or may not work."

Tier 3 requirements would be *very weak*:

* No buildbot requirement
* No assigned core dev needed
* Don't revert a change breaking a Tier 3 platform
* Don't hold a Python release if a Tier 3 platform is broken


As Brett pointed out a tier 3 platform does not make much sense if we 
have no means to test the platform. I also would like to nudge vendors 
to contribute resources like build bots or engineering time. We want a 
low bar for contributions. No bar is too low. :)


How about:

* a buildbot is required. For a transition period a public CI system, 
that runs Python's test suite at least once per day, is also acceptable.


* at least one active contributor who acts as a point of contact, 
monitors CI and provides fixes in a timely fashion.


Christian

___
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/CUBFMUL7SQZ6M2K6WK7XD2K2FGHDOUUJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Christian Heimes]

On 14/03/2022 19.37, Brett Cannon wrote:



On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner > wrote:


Hi Brett,

You can put my name as Contact of all Fedora and RHEL platforms.

Note: Fedora "Rawhide" is the rolling release and it's common that
these buildbots are broken by kernel, compiler or glibc updates,
rather than actual Python regressions. Time to time, it detects real
Python regressions. Tier 2 should only target Fedora *Stable* (which
is the case ;-)).

 > glibc XXX [fedora-stable]

Mentioning that Fedora uses glibc is nice, but I don't think that it's
worth it to mention the glibc version. Fedora is released every 6
months and the glibc version is updated at each Fedora release.



Christian had suggested/asked for that. So are people okay dropping the 
glibc version and instead documenting that it's testing glibc instead of 
e.g. musl?


Looks like I was not communicating my intention clearly. I don't want to 
list libc ABI and Kernel ABI of every targeted distro. Instead I would 
like to include only the glibc version of the oldest manylinux wheel 
standard that is supported by PyPI.


glibc has a strong forward compatibility guarantee. If something works 
with glibc 2.17, then it will also work with 2.34. A minimum glibc 
version sets the minimum feature set that we can rely on. If we say that 
Python is tested with glibc 2.17 and Kernel ABI 3.10 (CentOS 7), then we 
set CentOS 7 a baseline for users that also covers Debian Oldstable.


glibc and Kernel ABI are relevant for some features like getrandom() 
syscall, memfd_create, and similar.


Christian
___
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/U3UGOETJAR6FZRUV7UXS6FTDW57OEMRS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Christian Heimes]

On 11/03/2022 18.08, Marc-Andre Lemburg wrote:

All other platforms
===

- Only code which either supports a higher-tier platform or is a general 
improvement may be checked in.


My understanding of that sentence is: PRs which target platforms
not listed in PEP 11 may not be checked in.

IMO, it doesn't make sense to prohibit support code in the
code base, if there is community interest in this. By dropping
that line, we wouldn't have a problem and also don't
need to list platforms in a tier 4 section, since it's still
possible to add support in the main code base, without having
a core dev maintain it.


Community interest is not sufficient. A supported platform needs active 
engagement and contributions by the community or vendor. At a bare 
minimum a platform needs a core developer, who is interested in the 
platform, and a credible statement, that a buildbot will be provided in 
the near future.


Please note that the text of the rule is "may be checked in", not "core 
devs are forbidden to check in". There is a gray area for trivial 
patches or aspiring platforms. The rule gives us an easy way to refuse 
patches that cannot be tested. It also gives vendors a list of 
requirements as well as motivation to contribute buildbots.


Christian
___
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/M2P5ZTL2WDPK2BAL46YQUS5VQDJ65PVH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Christian Heimes]

On 11/03/2022 10.18, Marc-Andre Lemburg wrote:

I think the list is missing some important platforms which we do
support (looking at configure):

* Linux on 32-bit ARM platforms, e.g. for Raspberry Pis
* Linux on Android
* AIX
* Cygwin
* NetBSD/OpenBSD
* musl instead of glibc for Linux, e.g. for Alpine images


These platforms are missing on purpose. None of these platforms have a 
stable buildbot and tests are failing on most of them.


- Greg is running an unstable buildbot on an RPi at home, so RPi may fit 
into Tier 3.


- Alpine / musl is not supported, because our test suite is failing due 
to bugs and missing features in musl libc.


- NetBSD and OpenBSD are in a similar state as Alpine: no stable 
buildbot and AFAIK tests are failing


- Android is no longer actively maintained

- Cygwin and MinGW are officially unsupported, see bpo-45537 and bpo-45538

___
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/IQ7X75RG5DFMUAHCNZFEJEH5DOEJPN7K/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Christian Heimes]

On 11/03/2022 00.35, Brett Cannon wrote:
I brought this up on python-dev at 
https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ 
<https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/> 
, and the feedback seemed supportive. As such, I am bringing a draft of 
what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders 
for people to help me fill in to see how this will look overall.


For any platform(s) you support, please reply with any relevant details 
that should be added to the relevant tables below. Once I have these 
details I will loop back with the proposed update to PEP 11 and make 
sure everyone is still on board with the proposal.



A few remarks:

autoconf, GCC, and Debian call it "Target Triplet". Clang and Rust use 
"Target Triple". Should we stick with the clang name or use the GCC name?


Target triplets are machine-vendor-os. They come in short, normalized 
form and in long, extended form. The normalized form often omits the 
vendor field. Your document has both long and short forms. 
"wasm32-unknown-emscripten" is extended form for "wasm32-emscripten", 
while "x86_64-windows-msvc" is the short form of 
"x86_64-pc-windows-msvc". I recommend to stick to one convention.


By the way config.guess script and gcc can dump the current triplet. The 
config.sub script can be used to normalize and validate a triplet (does 
not work for MSVC). The output of config.guess is more specific than the 
gcc machine info. Here is a dump from my RPi:


$ ./config.guess
armv7l-unknown-linux-gnueabihf
$ gcc -dumpmachine
arm-linux-gnueabih
$ ./config.sub arm-linux-gnueabihf
arm-unknown-linux-gnueabihf


= == 
== 
Target Triple             Notes                      Buildbot   
                             Contacts
= == 
== 
wasm32-unknown-emscripten XXX                        XXX 
                            Brett Cannon, Christian Heimes
wasm32-unknown-wasi       XXX                        XXX 
                            Brett Cannon, Christian Heimes
= == 
== 


It's a bit premature to add wasm32-wasi. Python doesn't even compile on 
WASI yet.


Christian
___
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/XVVSUA4MGOSO7UXY4ISSGGSYKPUXPTQ4/
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

[Christian Heimes]

On 16/06/2021 10.50, Antoine Pitrou wrote:
> 
> Le 16/06/2021 à 10:33, Christian Heimes a écrit :
>> On 16/06/2021 07.14, Julien Palard via python-committers wrote:
>>> I do use a Yubikey too.
>>>
>>> Le 6/14/21 à 11:27 PM, Tim Peters a écrit :
>>>> If I buy one and plug it in, and that's the end of it, fine by me
>>>
>>> That's almost as simple as you want:
>>>
>>> - In Github settings 2FA tab you'll have to hit a "Register a new
>>> security key" button, it make your key "blink" (blinking mean: please
>>> touch the key to allow this action).
>>>
>>> - Then every time you login your key blinks and you have to touch it to
>>> allow this action.
>>>
>>> And that's it. It uses an open standard called U2F [1] which works on a
>>> variety of setups (it works with Firefox on Debian for example). It also
>>> works on pypi.org \o/.
>>>
>>> If the PSF is willing to help financially, I'd recommend everyone to buy
>>> (and register) two keys: a primary key and a backup key in case you
>>> loose or break the first one.
>>
>> Most sites with MFA support have backup/recovery codes, too. I recommend
>> that you generate backup codes, print them out and store the printout
>> with your important documents. It's low tech and safe.
> 
> It's as reliable as printing passwords on a piece of paper, isn't it?

No, recovery codes on paper are much more secure than printing passwords
on paper.

Passwords give an attacker immediate access to your account.

Recovery codes only contain one-time use second factors. They are
useless without the first factor (password). You keep recovery codes at
home, too. An attacker would need to get access to your first factor and
then break into your apartment to locate and steal your second factor.

Christian
___
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/JK67MJV44WV7V5UAJ2H4EL62CLG75OFY/
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

[Christian Heimes]

On 16/06/2021 07.14, Julien Palard via python-committers wrote:
> I do use a Yubikey too.
> 
> Le 6/14/21 à 11:27 PM, Tim Peters a écrit :
>> If I buy one and plug it in, and that's the end of it, fine by me
> 
> That's almost as simple as you want:
> 
> - In Github settings 2FA tab you'll have to hit a "Register a new
> security key" button, it make your key "blink" (blinking mean: please
> touch the key to allow this action).
> 
> - Then every time you login your key blinks and you have to touch it to
> allow this action.
> 
> And that's it. It uses an open standard called U2F [1] which works on a
> variety of setups (it works with Firefox on Debian for example). It also
> works on pypi.org \o/.
> 
> If the PSF is willing to help financially, I'd recommend everyone to buy
> (and register) two keys: a primary key and a backup key in case you
> loose or break the first one.

Most sites with MFA support have backup/recovery codes, too. I recommend
that you generate backup codes, print them out and store the printout
with your important documents. It's low tech and safe.

Christian
___
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/DP327KUOLMGVHUDTGTXPK6VJFSEHV4ZP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

[Christian Heimes]

On 25/05/2021 00.45, Pablo Galindo Salgado wrote:
> Hi,
> 
> Tomorrow is the scheduled release of Python 3.10 beta 2 but
> unfortunately we have several release blockers:
>
> https://bugs.python.org/issue44043 :
> 3.10 b1 armhf Bus Error in hashlib test: test_gil

The problem is already fixed. I forgot to close the release blocker bug
after Greg and I took care of https://bugs.python.org/issue36515.

Christian
___
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/GSGRKOGDZICAX7RJRBWNVKHFQAE5EWVQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Christian Heimes]

On 16/03/2021 16.54, Julien Palard wrote:
> Le 2021-03-16 à 15:52, Christian Heimes a écrit :
>> could you please explain your use case? Which problem are you trying to
>> solve? How would a sha256 checksum help you solve that problem?
> 
> No, I'm just forwarding the surprise of a user seen on a random social
> network (I'm monitoring the python hashtag on mastodon those days).

The MD5 fingerprint is really just a checksum to detect download issues.
Any checksum would do the trick, even CRC-32. We could (and should)
replace the MD5 fingerprint with SHA-256 or SHA-512 [1].

In our case SHA-256 checksums don't provide any real benefit over MD5.
Security and data integrity is provided by TLS / HTTPS and optionally by
GPG signatures. The Python source code and checksums are provided by the
same server. If an attacker is able to modify the tar ball, then it's
likely they can replace the checksum information, too.

tl;dr If you want to check for partial / bad downloads, then MD5 is
still OK. If you want to check for compromised files, then simple
SHA-256 checksums provide no extra security. GPG signatures are
problematic because GPG is awful. Sigstore [2] might become an
alternative in the future.

Christian

[1] On modern hardware SHA-512 is up to 50% faster than SHA-256.
[2] https://sigstore.dev/
___
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/RCFCPK5LSGKZ4LVZ4UHB2R52MD4CWTFV/
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Christian Heimes]

On 16/03/2021 14.59, Julien Palard via python-committers wrote:
> Hi,
> 
> Someone on Mastodon had me noticed that:
> 
> => https://www.python.org/downloads/release/python-392/
> 
> gives the md5 sum of Python builds, and that we should probably do better.
> 
> What about sha256? Has it been discussed already?

Hi Julien,

could you please explain your use case? Which problem are you trying to
solve? How would a sha256 checksum help you solve that problem?

Christian
___
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/C4JQAZ6TXTFS4XQ6BQIOCPAOHTXZARYL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is Tests / Ubuntu broken at the moment?

[Christian Heimes]

On 03/03/2021 18.59, Senthil Kumaran wrote:
> On Wed, Mar 3, 2021 at 8:08 AM Christian Heimes  wrote:
> 
>> PEP 644 (not approved yet) and a soon-to-be-published PEP will hopefully
>> get rid of the problem once and for all. PEP 644 removes support for
>> OpenSSL < 1.1 and the new PEP will remove support for TLS 1.0 and 1.1
>> from stdlib.
>>
>> https://www.python.org/dev/peps/pep-0644/
> 
> Thank you for all the efforts here, Christian. The PEP provides a good
> summary on the state.
> +1 vote to it and hope we will have a much simpler system to reason with soon.
> 
> It was hard for me (guess anyone) to track Libre/Open/Boring, TLS
> versions etc, and leave alone keeping it compatible like you have been
> doing.
> The premise of PEP-0644 is extremely reasonable.

Thanks! :)

It's actually easy:

- BoringSSL is irrelevant unless you have a product that bundles/vendors
the library as an internal dependency, e.g. Chrome.
- LibreSSL is used by OpenBSD and DragonFly.
- Everyone (*) else uses OpenSSL or moved back to OpenSSL

(*) except for Windows, macOS, Android, Java, Firefox/Thunderbird,
GnuPG, embedded systems, curl, and others. curl has something like 15
different TLS backends.
___
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/ZBQ6NJYJVF336CQ7Y7GIYYDWRNGVNLTL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is Tests / Ubuntu broken at the moment?

[Christian Heimes]

On 03/03/2021 21.54, Brett Cannon wrote:
> Has this been submitted to the SC yet? I can't find an email or anything
> at
> https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644
> .

Err ... no. I was not aware that I have to formerly submit a PEP to the
SC for approval. I thought that pushing the PR and announcing it on DPO
was good enough.

Christian
___
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/2IQJVA7YDSAPR2QV3KCVK2G6URQFKLMD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is Tests / Ubuntu broken at the moment?

[Christian Heimes]

On 03/03/2021 16.06, Senthil Kumaran wrote:
> On Tue, Mar 2, 2021 at 8:29 PM Gregory P. Smith  wrote:
>>
>> For lack of better things to do with that... 
>> https://bugs.python.org/issue43382 filed to track it.
> 
> Actually, that turned out to be useful. Thank you!
> 
> The discussion with the default minimal level TLS, and way it is
> configured in distributions like Ubuntu, Debian, Fedora, and it's
> usage with Python is  bit _unsettling_ from a users perspective.
> OpenSSL, Ubuntu, Python are heavily relied upon pieces of
> infrastructure. I wouldn't be surprised if more projects noticed this
> problem with the update to Ubuntu 20.02.

Hi,

for the record, the issue started when GitHub Actions updated
"ubuntu-latest" was updated from 18.04 to 20.04. A user reported a
similar issue on BPO last year in August and with Ubuntu last year in
October. Only Ubuntu is affected. Debian, standard OpenSSL, and other
distros use a different approach set minimum protocol version:

https://bugs.python.org/issue41561
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625


PEP 644 (not approved yet) and a soon-to-be-published PEP will hopefully
get rid of the problem once and for all. PEP 644 removes support for
OpenSSL < 1.1 and the new PEP will remove support for TLS 1.0 and 1.1
from stdlib.

https://www.python.org/dev/peps/pep-0644/


By the way, all major distributions disable TLS 1.0 and 1.1. They also
set a higher security level to block weak RSA, DH, and signatures. You
can find more information about Fedora crypto policies at:

https://fedoraproject.org/wiki/Changes/CryptoPolicy
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2


Here are some of my fixes for crypto policies, TLS 1.0/1.1 deprecation,
and FIPS:

https://bugs.python.org/issue34399
https://bugs.python.org/issue38275
https://bugs.python.org/issue38271
https://bugs.python.org/issue34542

Christian
___
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/JO3PCRIIG36GW2ZBRCSWUHNBXPUURYUW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Welcome Batuhan Taskaya to the team!

[Christian Heimes]

Welcome Batuhan!
___
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/Y4L4H3LXZU67ZBH43DOSVMUMF5SENKUX/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Christian Heimes]

On 23/07/2020 09.52, Matthias Klose wrote:
> Apparently there was agreement to hide this kind of information, and that's
> worse than the original behavior that was acted on. Who will be next? For what
> reason?  I am not questioning the decision, at least we voted for our 
> delegates,
> so I have to respect that decision even if I would disagree.  If you don't 
> want
> to communicate in public, then email committers separately, or create a 
> private
> ML for committers.

python-committers has a public mail archive. Anybody is able to follow
python-committers discussions via the public mailing list interface. I
understand why the SC is avoiding name calling in public.

Barry, multiple core devs have raised a concern now. There is at least
one more CoC violation under investigation, which is going to cause even
more concern. Would it make sense to disclose more details on the matter
in the private area on discuss.python.org? We have an internal forum
that is only accessible by core devs and PSF staff. That way the SC can
disclose more information in a  private post without public name calling
and public shaming.

Christian
___
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/MTQ4VWDGMGDIO6VA4ZIVTAYXXSJV2SES/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Christian Heimes]

On 22/07/2020 21.45, Ivan Levkivskyi wrote:
> What's the point of sending this to everyone? Why wasn't this sent as a
> quote?
> Anyway, this doesn't change my decision.

Hi Ivan,

the message was sent to python-committers. All active Python core
developers are subscribed to this mailing list and only core devs can
post here.

There has been a recent incident on a public mailing list. I see the
message from the SC transparent communication without publicly shaming a
specific person. It contains sufficient information for people involved
in the issue without disclosing the name of the offender.

In case you are not aware of the incident then you are in a lucky
position. I have followed part of the incident and consider the verdict
a mild judgment.

Christian
___
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/MARKZDXRZWSAIFTFP3Q6RIP7IRQOFOTG/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: 3.7.4 final delayed [Was: Python 3.7.4rc1 (and 3.6.9rc1) cutoffs ahead, now set for 2019-06-17]

[Christian Heimes]

On 29/06/2019 21.53, Ned Deily wrote:
> On Jun 6, 2019, at 01:43, Ned Deily  wrote:
>>
>> https://discuss.python.org/t/python-3-7-4rc1-and-3-6-9rc1-cutoffs-ahead-now-set-for-2019-06-17/1824
>> [...]
>> Following the rc1 cutoff, changes merged to the
>> 3.7 branch will be released in 3.7.5 three months from now unless you
>> mark the issue as a release blocker prior to **3.7.4 final**, planned for
>> release on **2019-06-28**, and explain why the change should be
>> cherry-picked into the final release.
> 
> Update:  3.7.4 final is delayed at least a few days
> 
> A few last minute release blocker issues were identified shortly before 3.7.4 
> final was about to tagged as planned on 2019-06-28, in particular, a couple 
> of TLS 1.3 issues which are of particular importance since we are migrating 
> Windows and macOS installers to OpenSSL 1.1.1 with this release.  We are now 
> on hold awaiting resolutions for the remaining items and then we will need to 
> decide whether another release candidate is needed.  I am hopeful we will be 
> able to proceed by Monday 2019-07-01; I will keep you updated.  And thanks 
> for your help!

Thanks Ned!

the issues are related to TLS 1.3 and client cert authentication. TLS
1.3 dropped renegotiation in favor of rekeying and post-handshake
authentication. PHA is required for conditional authentication in HTTP,
e.g. when a server only requires authentication for some paths or
request methods.

PR https://github.com/python/cpython/pull/14421 fixes a regression in my
PHA code for Python's ssl module. OpenSSL behaves slightly differently
than documented. SSLContext.post_handshake_auth = True also enabled
server cert validation. Alex has reviewed the PR but likes to have a
second opinion.

PR https://github.com/python/cpython/pull/14448 enables PHA for http.client.

Christian
___
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/46U6OW6UQ7AGVKF6XIJVL7SPT3MKTDI3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Zackery Spytz got the bug triage permission

[Christian Heimes]

On 07/06/2019 00.12, Victor Stinner wrote:
> Hi,
> 
> I decided to give more responsibilities to Zackery Spytz as a reward
> for his hard commitment over the last year and a half into Python: I
> gave him the bug triage permission.

+1

I worked with him on a couple of bugs, e.g. the memfd_create. He does a
good job.

Christian
___
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/WUZNQLX2GAETCZT62SRLL7NYDLYH7Y7F/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Christian Heimes]

On 20/09/2018 22.25, Antoine Pitrou wrote:
> 
> Hi,
> 
> I'm choosing to forward this to python-committers because I don't think
> python-ideas is a reasonable place to discuss CoC decisions.
> 
> I think the action taken by Brett (apparently decided with Titus and a
> mysterious "conduct working group") is not the right one:
> 
> - a definitive ban is an extremely strong decision that should only be
> taken if nothing else works.  May I remind that Anatoly was able to post
> prolifically and unconstructively for several years, being warned
> several times, before being finally banned?  Comparatively, this one ban
> seems expeditive.

In my opinion it's both wrong and unfair to compare the ban with
Anatoly's ban. For one we didn't have a process and general consent for
bans. It took us a while to agree on the procedure. Also Anatoly wasn't
flat out hostile and insulting. He was mentally draining and exhausting
on a more subtle level.

I'm all in favor to ban people from python-dev or python-ideas for
deliberate misuse and insults. Participation on these mailing lists is a
privilege, not a right. We grant the privilege to everybody, but also
reserve the right to remove the privilege.

Brett, Titus, I support your decision.

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Christian Heimes]

On 21/09/2018 12.46, Antoine Pitrou wrote:
> 
> Le 21/09/2018 à 02:06, Nathaniel Smith a écrit :
>> Now sure, that taboo is an American thing, and I wouldn't support
>> automatically banning someone who used it in genuine ignorance, was
>> repentant when they realized what they'd done, etc.
> 
> So why are American taboos specifically forbidden, and not other taboos?
>  Is there anything special about Americans that deserves this?  Does it
> mean that Python is a community for Americans foremost, and others are
> just second-class participants?  The more this is going on, the more it
> is the impression I get, and things have become distinctly *worse* recently.

I don't understand why you are drawing the reverse conclusion here. Can
you give me one concrete example, in which a French, German, or any
other non-US American taboo was violated and not counteracted with swift
reaction?
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 3.7.1 and 3.6.7 Releases Coming Soon

[Christian Heimes]

On 19/09/2018 23.12, Ned Deily wrote:
> Update: not surprisingly, there have been a number of issues that have popped 
> up during and since the sprint that we would like to ensure are addressed in 
> 3.7.1 and 3.6.7.  In order to do so, I've been holding off on starting the 
> releases. I think we are now getting close to having the important ones 
> resolved so I'm going to plan on cutting off code for 3.7.1rc1 and 3.6.7rc1 
> by the end of 2018-09-20 (23:59 AoE).  That's roughly 38 hours from now.
> 
> Thanks for all of your help in improving Python for everyone!

Hi Ned,

I'm really sorry, but would it be possible to delay the RCs until Sunday
or Monday AoE?

Some of the XML security fixes, OpenSSL 1.1.1 fixes (TLS 1.3
post-handshake authentication), and SSL module regression haven't landed
yet. I'm confident that I can land most to all fixes during the weekend.

Related PRs are:

* https://github.com/python/cpython/pull/9468
* https://github.com/python/cpython/pull/9460
* https://github.com/python/cpython/pull/9217
* https://github.com/python/cpython/pull/9265

I'm also still collaborating with Sebastian Pipping (libexpat
maintainer) on the DoS mitigations (CVE-2013-0340). My initial patch had
some flaws. I might be able to get expat release 2.3.0 in time, too.

https://github.com/libexpat/libexpat/pull/220

Christian

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel

[Christian Heimes]

On 14/09/2018 12.28, Raymond Hettinger wrote:
> At the developer sprints this week, we collectively decided to grant core 
> committer status to Emily and Lisa.
> 
> Please join me in welcoming them to the team.

Welcome on board!

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] I have blocked someone from the Python org

[Christian Heimes]

+1

Thanks, Brett!
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Language moratorium

[Christian Heimes]

On 2018-07-18 20:47, Barry Warsaw wrote:
> On Jul 18, 2018, at 09:11, Stefan Krah  wrote:
> 
>> if I remember correctly, we had a moratorium for language changes around
>> versions 3.2-3.3.  I think during that time relatively few BDFL-level
>> decisions were required.
>>
>> Perhaps we could have one again, say for 12 months so we can figure things
>> out. Other Python implementations may welcome the moratorium so they can
>> catch up.
> 
> I agree that we’ll effectively have language moratorium until we have a new 
> governance structure.  But let me ask, what do you propose to do about PEP 
> 572?  That’s already been accepted, but not yet implemented.  Would it be 
> exempt from the moratorium or scoot in under the wire?

It's the last will of our beloved dictator.

To quote my favorite Marvel villain: The first order of the new BDFL
cannot undo the last will of the previous BDFL.

Christian



signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Christian Heimes]

On 2018-07-12 20:50, Brett Cannon wrote:
> IMHO the N-virate should primarily be responsible for delegation.
> 
> Side note: I think we'll be talking less and less about language design,
> and instead about library and infrastructure design.
> 
> 
> Same here. I suspect this will make us much more conservative in
> accepting language changes compared to e.g. what our deprecation policy
> should be.

+1

- Primary to delegate responsibilities to domain experts
- Secondary to provide consistency and trust
- Lastly to have final word in case of controversial bike shedding

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Christian Heimes]

On 2018-07-12 20:02, Yury Selivanov wrote:
> Another worry -- Guido knows mostly everything about all aspects of
> Python design in all fields.  To illustrate my point, I'm particularly
> worried about async/await, asyncio/trio/twisted ecosystem -- so far it
> seems that it's only Guido and I who've spent a huge chunk of their
> time maintaining (or caring about) it.  We have many other critical
> fields besides async: general language design, packaging, scientific
> ecosystem, web (partially overlaps with async), performance, etc.
> Essentially we need to build our N-virate to have knowledgable
> representatives (formally known as BDFL-delegates) from all of those
> fields, otherwise the language can stop evolving in some important
> directions.

I understand that you are worried. But you don't have to be member of an
hypothetical N-virate in order to stir asyncio into the future. I
assumme that the trusted and wise members of the N-virate will recognize
you as domain expert for asyncio and listen to your advise. We already
have the concept of BDFL delegate for PEPs and should adapt the idea.

As Brett pointed out in one of his replies, N-virate should guarantee
long-term stability and consistency of the language. It's not the job of
the N-virate to control every little details. I envision the gremium a
bit like SCOTUS. SCOP, Supreme Court of Python, has a nice ring.

Christian


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Christian Heimes]

On 2018-07-12 16:57, Guido van Rossum wrote:
> Now that PEP 572 is done, I don't ever want to have to fight so hard for
> a PEP and find that so many people despise my decisions.
> 
> I would like to remove myself entirely from the decision process. I'll
> still be there for a while as an ordinary core dev, and I'll still be
> available to mentor people -- possibly more available. But I'm basically
> giving myself a permanent vacation from being BDFL, and you all will be
> on your own.
> 
> After all that's eventually going to happen regardless -- there's still
> that bus lurking around the corner, and I'm not getting younger... (I'll
> spare you the list of medical issues.)
> 
> I am not going to appoint a successor.
> 
> So what are you all going to do? Create a democracy? Anarchy? A
> dictatorship? A federation?

Thanks for being our beloved BDFL for so many years!

The mail doesn't come to an suprise, although I didn't think it would
hit my inbox this year or next year. I've been pondering about possible
succession for you for a while. In my opinion we need some trusted
entity to have final say. Otherwise we are going to waste^H^H^H^H^H
spend too much time in bike shedding. But I don't see one clear person
to take your place as BDFL.

How about a form of presbyterian polity in the form of a triumvirate or
quintumvirate? (For those with a lucky childhood that didn't involve
Latin and Greek: ruling of elders with three or five powerful
individuals). It would spread the load and responsibilities between
multiple core devs.

I would consider (in alphabetical order) Barry, Brett, Mariatta, Mark,
Nick, or Victor as potential members. Each persons has been a core dev
for a long time and would brings a unique perspective into the
quintumvirate. For example Mark Shannon has an academic background in
language design.

Regards,
Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Triage perms for Elvis

[Christian Heimes]

On 2018-05-29 23:45, R. David Murray wrote:
> At Yuri's request I've given Elvis triage privileges on the tracker.
> I don't anticipate any objections, given the work he's done on
> What's New and other things.

+1
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposing Mark Shannon to be a core developer

[Christian Heimes]

On 2018-05-14 16:41, Larry Hastings wrote:
> 
> 
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
> writing both the PEP and the implementation.  This shipped in Python 3.3
> and was listed as one of the top features of that release as according
> to the "What's New?" document.
> 
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.  At the time he said he didn't like
> our antiquated workflow.  Now that we've switched to the git-based core
> dev workflow, this objection is gone, and he's now interested in
> accepting the commit bit and the responsibilities that it entails.
> 
> I suspect you, my colleagues in CPython core development, will be
> surprised at the current state of affairs.  I'm expecting a load of "you
> mean Mark *isn't* a core developer yet?" replies.
>

+1
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?

[Christian Heimes]

On 2018-05-02 11:49, Victor Stinner wrote:
> Hi,
> 
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
> 
>https://www.python.org/dev/peps/pep-0572/
> 
> The poll is on the *current* PEP. I propose 4 choices:
> 
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)

-1
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Welcoming Petr Viktorin as our newest core developer :)

[Christian Heimes]

On 2018-04-23 17:43, Ethan Furman wrote:
> On 04/23/2018 07:39 AM, Nick Coghlan wrote:
> 
>> With my recent proposal to accept Petr Viktorin as a specialist core
>> developer focusing on extension module imports receiving several +1's
>> and no concerns being raised,
> 
> Where did this conversation take place?  I see no record of it here nor
> on the Zulip Chat channels.

We discussed the matter 10 days ago on this very mailing list,
https://mail.python.org/pipermail/python-committers/2018-April/005276.html

>> I'm happy to report that Brett has now
>> granted Petr his additional access on GitHub, the issue tracker, and
>> this mailing list.
>>
>> Welcome, Petr! :)
> 
> Yes, welcome, Petr!

Welcome! :)

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposing Petr Viktorin as a specialist core developer

[Christian Heimes]

On 2018-04-13 14:13, Nick Coghlan wrote:
> Hi folks,
> 
> I'd like to propose Petr Viktorin as a specialist core developer,
> focusing on extension module imports.

+1

I know him personally from work. He is a good engineer and responsible guy.

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] ssl module will require OpenSSL 1.0.2

[Christian Heimes]

On 2018-01-26 23:09, Christian Heimes wrote:
> On 2018-01-26 23:03, Victor Stinner wrote:
>> 2018-01-26 20:47 GMT+01:00 Christian Heimes :
>>> LibreSSL does not yet implement these APIs yet
>>
>> Does it mean that Python 3.7 will not support OpenBSD anymore? Well,
>> it's not like OpenBSD support is perfect, but there are only few
>> issues on OpenBSD.
>>
>> Does other operating systems use LibreSSL as their system SSL library
>> (instead of OpenSSL)?
> 
> OpenBSD is still supported. But you either have to install OpenSSL, live
> without SSL support or get LibreSSL fixed. Python's test suite is
> passing without ssl available.

According to https://en.wikipedia.org/wiki/LibreSSL#Adoption Alpine
Linux, DragonFly BSD and OpenBSD are affected.
https://distrowatch.com/table.php?distribution=openbsd still suggests
that OpenBSD ships with OpenSSL 1.0.2l. Not sure if that is true, though.

All other distributions either have only OpenSSL (CentOS, Debian,
Fedora, RHEL, Ubuntu), OpenSSL as default (Gentoo, FreeBSD) or none
(Windows, macOS). NetBSD seems to support both.

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] ssl module will require OpenSSL 1.0.2

[Christian Heimes]

On 2018-01-26 23:13, Victor Stinner wrote:
> 2018-01-26 23:09 GMT+01:00 Christian Heimes :
>> OpenBSD is still supported. But you either have to install OpenSSL, live
>> without SSL support or get LibreSSL fixed. Python's test suite is
>> passing without ssl available.
> 
> (Sure, if LibreSSL is fixed, the issue goes away, but right now
> https://github.com/libressl-portable/portable/issues/381 is still
> open.)
> 
> I'm not sure that it's possible to easily install OpenSSL on OpenBSD.
> OpenBSD is linked to the team who wrote LibreSSL and OpenBSD replaced
> OpenSSL with LibreSSL.
> 
> Python without ssl also means Python without pip. Python without
> pip... well, it's more limited than Python with pip :-)

We never officially supported LibreSSL, so we aren't breaking any
promise. I supported LibreSSL as a best-effort approach.

You can still have TLS support with extra packages. Python requests and
pip can also use PyOpenSSL.

Christian

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] ssl module will require OpenSSL 1.0.2

[Christian Heimes]

On 2018-01-26 23:03, Victor Stinner wrote:
> 2018-01-26 20:47 GMT+01:00 Christian Heimes :
>> LibreSSL does not yet implement these APIs yet
> 
> Does it mean that Python 3.7 will not support OpenBSD anymore? Well,
> it's not like OpenBSD support is perfect, but there are only few
> issues on OpenBSD.
> 
> Does other operating systems use LibreSSL as their system SSL library
> (instead of OpenSSL)?

OpenBSD is still supported. But you either have to install OpenSSL, live
without SSL support or get LibreSSL fixed. Python's test suite is
passing without ssl available.

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] ssl module will require OpenSSL 1.0.2

[Christian Heimes]

For your information,

my ssl module improvement "Let OpenSSL verify hostname and IP address"
will land either today or tomorrow. I'm just waiting for Alex to give me
the final ACK on PR https://github.com/python/cpython/pull/3462.

Once the PR has landed, several issues with hostname and IP address
verification will be solved. Python 3.7 will use OpenSSL's recommended
API to match hostnames. The API is OpenSSL 1.0.2+ only. OpenSSL 0.9.8
and 1.0.1 are no longer supported.

LibreSSL does not yet implement these APIs yet, see
https://github.com/libressl-portable/portable/issues/381 for my upstream
bug and
https://mail.python.org/pipermail/python-dev/2018-January/151824.html
for Python-dev discussion.


I also like to get https://github.com/python/cpython/pull/5259 into 3.7.
The PR adds support for OpenSSL's new API to set minimum and maximum TLS
protocol version. It's require for compatibility with future versions of
Debian. Debian has used the new APIs to disable TLS 1.0 and 1.1, see
https://bugs.python.org/issue31453.


PR https://github.com/python/cpython/pull/5162 implements PEP 543
Certificate and PrivateKey classes, but it's not finished yet. The code
works but it lacks tests and documentation.


My remaining TLS PRs are either bug fixes or can wait for 3.8. I'll
merge them after beta 1 has been released.

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

[Christian Heimes]

On 2017-12-12 02:17, Gregory P. Smith wrote:
> On Mon, Dec 11, 2017 at 12:26 PM R. David Murray  > wrote:
> 
> On Mon, 11 Dec 2017 14:56:21 -0500, Donald Stufft  > wrote:
> >
> > > On Dec 11, 2017, at 2:52 PM, R. David Murray
> mailto:rdmur...@bitdance.com>> wrote:
> > >
> > > If 2fa is required for contribution to CPython, I'll stop
> > > contributing.
> >
> > I’m curious why? I have it on and 99% of the time you don’t even
> > notice because you’re already logged into GitHub and pushes/pulls
> > don’t require it.
> 
> I had to use 2FA when working for a corporate client, and it was
> very annoying.  The fact that pushes and pulls don't require it
> helps, but also makes it considerably less important.
> 
>  
> Please Don't let /that/ experience color your 2FA opinion.  Not everyone
> $random_corp does a good job of it.
> 
> It does not have to be annoying.  Github's and Google's are examples of
> 2FA done right that is not annoying (using U2F).
> 
> But I suppose that fundamentally I do not want my security tied to a
> possession.
> 
> 
> *2FA doesn't need to be tied to a single possession.*  You are not
> limited to a single second factor thing.  You can have plentiful
> different two factor methods set up at once.  This is normal.  ex: A
> printed recovery code at the very least as a second second factor.  Have
> multiple U2F USB tokens tied to your account? Yes. I do that all the
> time on all accounts.
> 
> Heck, a photo/scan/screenshot of backup one time codes stored as a
> public image somewhere with no password authentication for the world to
> see on an http server still counts.  As laughable as that is, it is
> *still* much better than not having 2FA enabled at all.  Because it
> isn't going to be an automated attack at that point.
> 
> /Any/ 2FA is much better than no 2FA.
> 
> When (not if) your login/password is compromised, it is rarely your own
> fault. But your account and all of your data can be gone in a heartbeat
> as soon as anyone or anything malicious chooses to make it so on
> whatever selection of accounts they choose to victimize. Often
> irrecoverably. With 2FA enabled, that is much less likely to happen to you.
> 
> Try it. You will remain happy.
> 
> I recommend the https://www.yubico.com/product/yubikey-neo/ as a primary
> U2F token because it even works with Chrome on Android phones via NFC
> when you need to re-auth there.  That is a more expensive one, there are
> $10-20 alternative vanilla U2F USB tokens. I have some of those as
> backups. The "nano" style keys that you just leave in the USB port of
> all computers you use regularly are also a nice solution. no need to
> find and pull out the key, it is just present in your computers (it
> requires a physical touch to prevent remote access).
> 
> Which 2FA methods to choose is an individual choice, but in my
> experience since the U2F keys came out, I'm less inclined to use any
> service that doesn't support them as all other solutions are a worse
> user experience for me.
> 
> IMNSHO, the PSF /should/ be able to buy one or two U2F tokens for any
> committer who needs them.  This should not depend on a policy of 2FA
> use, it would just be a way to promote good security practices among
> committers  to make us all better off.

+1

If you don't the trust closed-source Yubico hardware, there is plenty of
other hardware out. https://www.nitrokey.com/ is good German engineering
with fully open-sourced hardware and software.

Adam has compiled a nice list of U2F and 2FA tokens, too.
https://www.imperialviolet.org/2017/10/08/securitykeytest.html

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Official python-dev docker images

[Christian Heimes]

On 2017-12-07 19:00, Barry Warsaw wrote:
> As part of the importlib_resources skunkworks project Brett and I have been 
> working on (just announced), we’ve also put together a nice Docker image that 
> we’re using for our automated testing.  This image is based on Ubuntu 16.04 
> and provides the latest stable releases of Python 2.7, and 3.4-3.6, along 
> with a mostly up-to-date git checkout of master, currently Python 3.7 of 
> course.  Once 3.7 is released to beta, we intend to track its release 
> tarballs too.
> 
> We also install a few other commonly needed tools, like pip, git, unzip, 
> wget, mypy, and tox.
> 
> Here’s the project repo:
> 
> https://gitlab.com/python-devs/ci-images
> 
> Huge shout out to Abhilash Raj who helped us clean up and compactify the 
> image, and also for setting up automated publishing to quay.io.  In case you 
> weren’t aware, Abhilash is who I passed GNU Mailman project leadership to, so 
> he has a lot of Python experience, and a ton of expertise in the image space. 
>  He’s an amazing amount of work to improve the quality of this image!
> 
> Brett and I want to promote this more widely within the Python community as 
> the “official Python Docker image” that projects can use in their own testing 
> environments, or base their own images on it.  We wanted to give you guys a 
> heads up first to get your feedback, and maybe thoughts on the best places to 
> promote this, e.g. on the python.org website or other places.
> 
> We welcome your participation too of course!  I’m happy to give write access 
> to the project to any Python committer who wants to help.

Shiny! You'll get extra bonus points for not running as root. :)

I'm curious, what is the reason of compiling CPython yourself? Ubuntu
has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and
3.5.

Could I convince you to put some builds of OpenSSL and LibreSSL into the
container, too? Ubuntu 16.04 has only OpenSSL 1.0.2. A while ago I added
a script to CPython that downloads, compiles and installs multiple
versions in a shared directory (../multissl relative to cpython
checkout). The script can be used to run the SSL test suites (ssl,
asyncio, urllib, smtp, ...) against all installed versions.

https://github.com/python/cpython/blob/master/Tools/ssl/multissltests.py

Regards,
Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Official python-dev docker images

[Christian Heimes]

On 2017-12-07 22:28, Barry Warsaw wrote:
> That’s good feedback!  I want to be clear about the purpose of this image, 
> both in that it’s blessed and maintained by us, and that its focus is on the 
> Python library and application developer (primarily for testing purposes).
> 
> So maybe: Python.Org Official Multiversion Development Docker Image 
> Doubleplus Good!

Why is there 'Docker' in the name? Is the container image restricted to
Docker runtime or can I use it with lxc, systemd-nspawn, rkt, or any
other container runtime, too?

There are likely legal issues with the name, too. After all 'Docker' is
a registered trademark of Docker, Inc [1]. I'd be careful and call it
'Python.Org Official Multiversion Development Supercalifragilistic
Container Image' instead.

Christian

[1] https://www.docker.com/brand-guidelines
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Hacktoberfest

[Christian Heimes]

On 2017-09-28 18:21, Mariatta Wijaya wrote:
> Hi,
> 
> October is hacktoberfest (https://hacktoberfest.digitalocean.com/) 
> In the month of October, people can sign up and contribute to open
> source projects on GitHub. If they make 4 PRs during Hacktoberfest,
> they'll earn a limited edition T-Shirt.
> 
> If it's ok with everyone, I want to create "hacktoberfest" label and
> apply it to some of the open issues in the DevGuide and core-workflow
> repo. The purpose of the label is to make the repo discoverable, so it
> shows up as one of the participating projects:
> https://github.com/search?q=label%3Ahacktoberfest+state%3Aopen+type%3Aissue&type=Issues

Sounds good to me.

Fun fact: The real Oktoberfest in München always starts mid of September
and ends on the first weekend of October. This year it will end on
October 3rd. Hurry up! :)

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] UPDATE 1: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California

[Christian Heimes]

On 2017-07-12 13:55, Łukasz Langa wrote:
> Update: the sprint is on!
> 
> *Good news*: Facebook is covering the venue, food and hotel costs. This
> is confirmed. I'm working on getting a PSF grant for flights like last year.
> 
> *Please book your* *airplane tickets* as soon as possible. Like last
> year, we can reimburse up to *$500* for domestic roundtrip flights and
> up to *$1500* for international roundtrip flights. If that’s not enough
> to get you to California and back, let me know and we’ll figure
> something out. Send me the receipts my way, you should get your money
> back before the event, preferably as soon as I get the grant wired. For
> sums smaller than $500, provide me with a PayPal e-mail. For larger
> ones, I will need your details to set up a wire transfer. I will use
> TransferWise for the latter to cut down the wire costs. * I recommend
> flying in on Sunday and flying out on Saturday.*
> 
> *Please DO NOT book hotels*, Facebook is covering this, preferably in
> the same hotel as close to Facebook HQ as possible. NOTE: I cannot
> confirm your hotel room until I have your flight information.

Hi Łukasz,

do you have any news on the hotel?

Several attendees including me use ESTA to travel into the US. We are
required to provide Advanced Passenger Information (API) a couple of
days up front. API also include the location of the first accommodation.
As far as I remember, I have to provide the name and address of the
hotel by the end of the week.

Regards,
Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] mention-bot is dead, long live the (misnamed) CODEOWNERS file!

[Christian Heimes]

On 2017-08-01 22:59, Brett Cannon wrote:
> For those of you who have not noticed, mention-bot is no more. We were
> using the free instance that Facebook provided, but it seems to have
> fallen over and it doesn't look like it's going to get fixed soon
> (https://github.com/facebook/mention-bot/issues/230).
> 
> But while mention-bot was down, GitHub launched a new feature that
> serves a related purpose. While mention-bot tried to guess who should
> review a PR based on who has committed (which led some of us to get
> mentioned a lot simply from having touched a bunch of files), that
> didn't guarantee people got listed as a reviewer when they specifically
> wanted to be (e.g. Christian wanting to know about PRs touching our
> hashing or SSL code).
> 
> But GitHub launched CODEOWNERS to cover that latter case
> (https://help.github.com/articles/about-codeowners/ ). Now the filename
> is misleading since it doesn't necessarily mean someone owns the code
> (there's an option to make it feel like that, but we will never flip
> that on), but basically what the file does is let us specify who should
> automatically be added as a review of a pull request when files changed
> by the PR match one of the rules in CODEOWNERS. We have now created the
> file thanks to Mariatta
> (https://github.com/python/cpython/blob/master/.github/CODEOWNERS) and
> started with what we had in our .mention-bot file (which was just some
> rules for Christian). But if there are any files you want to
> automatically be listed as a reviewer on automatically, then please add
> an appropriate rule to that file (remember that being listed as a
> reviewer doesn't require that you review else you block a PR from being
> merged, so don't view it as some major commitment).
> 
> Now to start we can specify individual people. But if there end up being
> groups of people who want to be added to reviews on certain topics (e.g.
> Eric, Nick, and myself for importlib stuff), then we can create
> sub-teams on GitHub of the Python Core team and then that team can be
> listed for the rule. To create a team just tell me who is on the team --
> all of whom will be made admins so teams are self-organized
> post-creation -- and what the team name should be (e.g. importlib-team).
> Then you can reference the team by e.g. @python/importlib-team (I think
> team names, even when nested, are not nested when mentioning so we will
> probably want to have a "-team" suffix for all teams to make it clear
> it's a subteam and not to clash with higher-level teams like
> @python/asyncio or @python/typing).

Marietta, Brett, thanks for your work!

I suggested teams to make the file a bit easier to maintain. The rule
format works differently than the old mentionbot format. In the old
format we had a relationship user -> files. The new CODEOWNERS format
has files -> users mapping with last rules trumps all semantic. We have
to be careful to not override parts of a previous rules. I believe teams
reduce the burden.

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposing Carol Willing to become a core developer

[Christian Heimes]

+1 from me
We need more experienced mentors and doc writers. 
Sent from my Android phone with K-9 Mail.___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Christian Heimes]

On 2017-05-03 19:54, Brett Cannon wrote:
> I just touched
> up https://github.com/python/cpython/blob/master/.github/CONTRIBUTING.rst to
> explicitly mention that only code review issues should be discussed on
> GitHub.

Thanks Brett!

I followed Donalds' advice and just pushed a modification to
.mention-bot
https://github.com/python/cpython/commit/feec3dc9c308052754f9e4848c1c1ddb007e9f66
. Let's wait and see if it actually works. :)

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Christian Heimes]

On 2017-05-02 20:28, Terry Reedy wrote:
> On 5/2/2017 10:07 AM, R. David Murray wrote:
>> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" 
>> wrote:
> 
>>> IMO, it's much easier for everyone to just always point people
>>> to BPO for discussions and keep PRs reserved for code reviews.
>>
>> I agree with Mark-Andre here.  It will take effort on our part to
>> make our culture be "discuss on BPO", but it will produce a much
>> superior history to what github PRs produce, so I think it is worth it.
> 
> It would easier to move discussion to bpo if there were a clickable link
> from PR to bpo, just as there is in the opposite direction.  I believe
> that there is a workflow issue to add this, but last I knew, it was
> bogged down in where to put the link, or something.

All recent PRs have a clickable link to BPO. It's in the box with CI
results. Click on "Details" for "bedevere/issue-number".

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Github reviews are cannibalizing BPO

[Christian Heimes]

Hi all,

since our move to Github I noticed a major increase in incoming patches.
I like it. It clearly shows that it was a good decision.

But I don't like the fact that Github reviews are cannibalizing issues
on BPO. Before the migration decisions regarding a new feature or bug
fix were made on the ticket system. For larger changes we used mailing
lists or the PEP process. Rietveld, our previous code review tool, was
just used to discuss code and implementation details. All important
decisions still happened on BPO. We also used BPO to keep the experts or
module maintainers in the loop.

With Github I'm seeing a major paradigm shift. New contributors tend to
use BPO as ticket number dispenser. Actual discussion seems to happen
mostly on Github PRs. For me it makes it harder to follow discussion or
to see discussions at all. I find Github notifications inferior to
compared BPO's email notification -- mostly because Github spams me with
notifications. For me it's not uncommon to have more than 1,000 open
notifications waiting for my attention.

This brings me to my questions

1) Should we try to move discussion back to BPO or are we fine with
having major decisions just in Github PRs?

2) How can we retain enough information on BPO to keep it useful as
research database for past decisions?

3) How can we keep module maintainers and experts in the loop? For
example I don't have the resources to read all Github PRs, but I still
like to keep an eye on the ssl and hashlib module.

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Date of the Language Summit at Pycon US 2017?

[Christian Heimes]

On 2017-02-24 11:30, Victor Stinner wrote:
> Hi,
> 
> I'm going to book my hotel and flight for Pycon US, but I don't know
> the date of the Language Summit and I would prefer to not miss it if
> possible :-)
> 
> Does someone organize it?

The language summit is usually on the first day of tutorials, so May 17,
https://us.pycon.org/2017/schedule/tutorials/ . [BL]arry are organizing
the summit.

Christian

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposed new core developer -- Mariatta Wijaya

[Christian Heimes]

On 2017-01-26 14:49, Nick Coghlan wrote:
> With Raymond volunteering as mentor, I think an approach where changes
> are still reviewed, but it's Mariatta that does the final commit would
> work.

+1

I followed some of Mariatta's work. She does a good job. I trust both
her and Raymond's judgement to do the right thing (tm).
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Call For Participants For The 2016 Python Language Summit

[Christian Heimes]

On 2016-03-03 08:45, Nick Coghlan wrote:
> On 2 March 2016 at 11:01, Larry Hastings  wrote:
>> It's that time once again: time to start planning for the 2016 Python
>> Language Summit!
> 
> Huzzah, thanks for organising this again!
> 
> I've forwarded the email to a few folks to suggest they submit
> presentation proposals, but I also have a question for everyone else:
> would folks be interested in a summary of the SSL/TLS handling
> developments over the past couple of years and open issues (aka
> "things that are still hard that we would prefer were simpler") we
> could potentially help with in core dev?

Thanks! TLS/SSL is already covered. :) I have invited Cory Benfield
(python-requests, urllib3, hyper). Cory and I are co-chairing a
presentation about the future of TLS/SSL in Python core and Python
ecosystem together. Let's hope 20 minutes are enough.

I have also proposed a short recap of Python Security, PSRT and Coverity
Scan activity in the past year. I also like to address communications of
security fixes. From the bug tracker it is not immediately visible,
which Python releases contains a fix. The changelog doesn't highlight
security fixes, too. This allowed one nasty bug to fly under the radar
and caused a downstream $VENDOR to not backport a fix. I'd like to have
security issues marked in the changelog, e.g. with "[S]" or "[SECURITY]"
prefix/suffix.

Christian




signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Anyone up for a core dev panel discussion at EuroPython 2016 ?

[Christian Heimes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-02-19 17:35, M.-A. Lemburg wrote:
> Hello all,
> 
> at this year's EuroPython we'll have a new officially supported 
> feature, the panel discussion, and we (I'm one of the organizers) 
> thought it would be big fun to have a panel of core developers talk
> about the merits of computed gotos, micro benchmarks, adding
> fast-paths for integer, free lists, and all those nifty things that
> core devs do in their spare time ;-)
> 
> No, seriously, this is great stuff normal Python users never get to
> see and that's really a shame.
> 
> So my question to you: will some of you attend EuroPython this year
> and would you be willing to talk on a panel ?

Hi MAL,

I might be coming to EP this year. I couldn't make it last year, this
year is looking better.

If I'm able to make it, I'm willing to participate in the panel
discussion. I can talk a bit about Python security and my work on the
PSRT.

Christian
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWyd8rAAoJEIZoUkkhLbaJbV8H/ijNrUG8pejhgjfSzotuAOmR
Af37UqI1kLGwvNjIxtGCXyirXT/rIJr2Fz/nlz5LeFiJH5cxK062ZVmXMLUjZHqn
B15DihJlPtFInucjglaGGE8sg90s++OjZT7vV2wOh12lTMWg/X2x1SR8KPle/C0o
4Jo+jGsnJHxDIvbMgi7Reo7vjEJ5IuJVRRGsbnzZPlJzxVWmNoe1LqyMAZsV7EjN
D+DCbk1vttCSg8gSjmhfRED5XVBkqNmvaHYvIOvmKBCQhaIA1tQXYbAobh4stcOO
WVjluIZutGeb05JuR2kOzEz6pad0JGbu7SkBwJiWEAyMUoaz6FF+mLQQiksU1fI=
=d3WO
-END PGP SIGNATURE-
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] You are invited to the Pycon 2015 Language Summit

[Christian Heimes]

On 21.01.2015 17:54, Barry Warsaw wrote:
> *Please* let us know if you plan to attend so we can size the room and other
> amenities accordingly.

I'll be there for the first time. It's also my first time at PyCon US
and first time outside Europe thanks to the financial aid program. My
current plan is to arrive on Tuesday 7th and stay until the last sprint
day on Thursday 16th.

Christian

PS: I'm also looking for somebody to share a hotel room or other
accommodation like an Airbnb apartment. I'm a non-smoker -- and I hardly
ever snore, too.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] MSDN renewals

[Christian Heimes]

On 02.05.2014 22:28, Brian Curtin wrote:
> Hi all,
> 
> I've been told there's a batch of MSDN subscriptions about to end
> soon, so if you're in that camp, please let me know if you'd like a
> renewal by giving the email address associated with your account as
> well as your subscription ID. You can find that ID at
> https://msdn.microsoft.com/subscriptions/manage/ when logged in.
> 
> As usual, if you need a first time subscription, let me know your
> preferred email, mailing address, and phone number (they don't mail or
> call you, but they are required fields).

Hi Brian,

my MSDN subscription wasn't renewed yet. Can you have a look, please?

Visual Studio Ultimate with MSDN
Christian Heimes, si...@cheimes.de
Subscriber ID:600694836

Status: Expired/In grace period
Expired on 2/14/2014

Christian

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

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

[Christian Heimes]

Am 04.12.2013 20:07, schrieb Benjamin Peterson:
> FWIW, the current plan is to have the last normal release in 2015
> and security releases "indefinitely" (2020 or something like
> that).

Can we make an exception for platform support, e.g. compatibility
fixes with new compiler or library versions? dpkg-architecture and
OpenSSL with SSLv2 have broken Python 2.6 builds.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

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

[Christian Heimes]

Am 04.12.2013 19:14, schrieb Michael Foord:
> 
> On 4 Dec 2013, at 18:13, Christian Heimes 
> wrote:
> 
>> Am 04.12.2013 19:01, schrieb Michael Foord:
>>>> I've added it to the agenda with your name...
>>>> 
>>>> As my name is being attached to a discussion of ending the 
>>>> development of Python 2, will there be a place for people to 
>>>> check their pitchforks at the door?  =)
>>>> 
>>> 
>>> On the contrary, I think I'll be selling pitchforks and
>>> popcorn...
>> 
>> Don't forget to bring a sharpening stone! :)
> 
> Sharpening popcorn doesn't work, I've tried it.

You haven't tried popcorn at my local cinema yet. It'll do the job ...
lots of large, diamond-hard sugar crystals.

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

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

[Christian Heimes]

Am 04.12.2013 19:01, schrieb Michael Foord:
>> I've added it to the agenda with your name...
>> 
>> As my name is being attached to a discussion of ending the
>> development of Python 2, will there be a place for people to
>> check their pitchforks at the door?  =)
>> 
> 
> On the contrary, I think I'll be selling pitchforks and popcorn...

Don't forget to bring a sharpening stone! :)
___
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

[Christian Heimes]

Am 29.11.2013 21:05, schrieb 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).

Thanks a lot for your mediating role. :)

> (*) 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.

python-legal and python-infrastructure, too.

Christian
___
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

[Christian Heimes]

Am 29.11.2013 19:14, schrieb 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.

"Several people" is an exaggeration. Only Kristjan is complaining and
he sure hasn't dealt with Anatoly before. Let's not forget that four
core devs have agreed to close the ticket.

Perhaps it's time to try a more technical approach and restrict
modifications of status, resolution, version and priority to core devs
or CLA signers. That could stop his rampage without further discussion.

___
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

[Christian Heimes]

Am 29.11.2013 16:04, schrieb Brett Cannon:
> 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 second the motion!

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

[python-committers] Fwd: Re: Fwd: Python at HackerOne

[Christian Heimes]

Here is another mail from Alex. I asked him about conflict of interest:


 Original-Nachricht 
Betreff:Re: Fwd: Python at HackerOne
Datum:  Thu, 7 Nov 2013 17:33:52 -0800
Von:Alex Rice 
An: Christian Heimes 



Our "easy fix" to the collusion issue is to request core developers
donate the bounty directly to a nonprofit instead of personal gain (the
nonprofit could be the PSF).

Attacking the problem directly requires a bit more structure. This would
be a start:

- transparent, consistent bounty amounts. This requires removing most
subjectiveness from the award process
- volunteer cannot be paid for a bug in code they wrote
- bug must have been *live* for 12+ months

But, to be honest, it's not a problem with one clearcut solution. If
there's a desire for a formal code of conduct (probably a worthwhile
exercise), we can take a first pass at drafting one and request feedback
from the community.

On Nov 7, 2013 8:19 PM, "Christian Heimes" mailto:christ...@python.org>> wrote:

Am 08.11.2013 01:45, schrieb Alex Rice:
> FYI :)

Hi Alex,

I totally forgot that it's a member's only mailing list. I have forward
your mail. Thanks for the heads-up! We are going to discuss your input
internally and get back to you in a couple of days.

I have one final question / remark for you:

Do you have a recommendation how we should handle conflict of interests
with IBB? After all a high percentage of security-related discoveries,
fixes and improvements are made by Python core committers or PSRT
members. Although we are all unpaid volunteers I (and probably others)
would feel uncomfortable to suggest fellow developers for a bounty. It
would feel like cronyism... Are you working on a code of conduct for
these kinds of problems?

Good night!
Christian



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

[python-committers] Fwd: Re: Python at HackerOne

[Christian Heimes]

Forwarded mail

 Original-Nachricht 
Betreff:Re: Python at HackerOne
Datum:  Thu, 7 Nov 2013 16:37:30 -0800
Von:Alex Rice 
An: Christian Heimes 
Kopie (CC): python-committers@python.org, IBB Panel




Hi Christian!

Thanks for getting in touch, glad there's interest on your end! Our
initial approach was structured to be as noninvasive as possible. The
simple version: we'll keep an eye out for public security patches and
reactively issue bounties for both the discovery & fix.

This passive approach is optimized for minimizing pain but leaves room
for efficiency gains given how removed we are from the project.
Fortunately, we have a lot of flexibility here and we welcome assistance
devising more effective means of rewarding outstanding security
contributions to the Python community. Here are a few options worth
mentioning:

- Our initial scope only covers the rare, high-severity bugs, because
we're a bottleneck that can't investigate every bug. This scope can be
expanded if you're willing to accept more submissions and provide a
severity assessment for confirmed bugs. For example, you might include
low-severity bugs (i.e., DoS) for ~$500.

- Please shout at us whenever you observe a contribution that you
believe made us all safer. You will undoubtedly have insight into each
vulnerability that we might have overlooked.

- We're happy to make suggested edits to the program's description at
https://hackerone.com/python

In general, you're the boss: feel free to think of this as the "Python
Bug Bounty". You tell us how the budget would be spent most effectively
and we'll work with you to strike a balance. As examples, the guys at
Phabricator decided to exclude bounties for patches (they'd rather fix
every issue themselves) and rewrote most of our scope from scratch.
Django is going through the same exercise right now.

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

[python-committers] Python at HackerOne

[Christian Heimes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

I'm contacting you on behalf of the Python core committers and Python
Security Response Team (PSRT). We were really excited and honored that
Python was selected as one of the twelve first projects for the new
Internet Bug Bounty program. Thanks a lot for including Python!

Is there anything the PSRT or Python Software Foundation can do to
join the effort and assist with your program? I think it's in our
mutable interest to spread the word and handle incoming security
issues properly. We will be glad to help you.

Regards,
Christian Heimes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJSe+w5AAoJEMeIxMHUVQ1FScgP/RFfopZobKp6Zm6m+/x3PLuK
drN6qNFz+bVTP0OWBjuADLOIJHMH2Bg4BdhBaxwz0gFF+f4g6iqr5bI4VJRhaDiE
Is99KzY7ZrMUy2OKC0MbrmbAxrWq8axmwel2u4wjCs/EH1qr794/fwExCEG8udzq
3KEzlBT5S+sxVvv8aXLeQX5fRyEAxr6saRtbXqThTZjL/MmZ0cb4f3eNfJDT4RTv
SDHRjnAC/OtrGr5Qg+0y+qX7Qa7+YcMvQXGmNIFIrunbUCGiODtBJAx8xsjZNFDP
6N28CprnHYo2fLkDJTC//QhIpdS+dsrHtEhNih1cxw5ZjMf28MQNEenPjFx27S//
gFkJC87JFV3cbWVFWZLM8j8im1tv+o2Ph09nrLj8QoApS5cgLB3LJXUy2b++rHOX
cw5OM3BlQt701KpV3ATuPspWQEELqlKB7+gOeJEdd0+XUrEQfIEMdiT6fZOEOE+N
qd+uPKRUNxxVC8kGne2GszhLXhHoeeBDK8EaTICr94Xw3ZVM8HaNBA6sykDdXEXn
QX8OjSrXbW9iyS63Aru6KoUZS0PdHAzSHLDQbzRJUMtaE39kxVe5zfLovgaPY3dH
zQnvotts5jvZ6K/G89dyNLqDRnGrZgPROKej1Uws82iah6GXO/3FTFSGrRmX4JUk
/9xOzzkdBMjS1EF6/ca+
=oUpk
-END PGP SIGNATURE-
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python bug bounty

[Christian Heimes]

Am 07.11.2013 11:45, schrieb M.-A. Lemburg:
> On 07.11.2013 11:40, Christian Heimes wrote:
>> Hi,
>>
>> this is going through the news right now. Has anybody contact us about
>> the bug bounty program for Python?
>>
>>   https://hackerone.com/python
> 
> FWIW, the PSF was not contacted about this in advance.
> 
> Sounds like a nice project, though.

The PSRT wasn't contacted either.

I like it, it's a great idea! It just came as a surprise to me. Should
we contact them and establish a work flow?

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

[python-committers] Python bug bounty

[Christian Heimes]

Hi,

this is going through the news right now. Has anybody contact us about
the bug bounty program for Python?

  https://hackerone.com/python

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

Re: [python-committers] Zachary Ware for commit access?

[Christian Heimes]

Am 01.11.2013 04:50, schrieb Brian Curtin:
> Hi all,
> 
> What do you think about giving commit access to Zachary Ware? He's
> been active on the tracker for a while and has contributed a good bit
> of Windows code.

+1 for a new Windows developer. :)

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

Re: [python-committers] PEP commit privilieges for Donald Stufft?

[Christian Heimes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am 14.08.2013 18:49, schrieb Nick Coghlan:
> Donald is the current main developer for PyPI and is doing a lot
> of work on PyPI related PEPs this days - it would reduce the 
> administrative overhead if he could update the related PEPs
> directly.
> 
> Any objections to my getting him to send his public SSH key to 
> hgaccounts for inclusion?

+1

He'll do great!

Christian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJSC7X7AAoJEMeIxMHUVQ1FUykP/2X7lWQ7LhI3r/6Sa94xmXeH
JgstvKviMA40+DGLGoVBBr38D2oi8uqtSRv0WzDEQf207ilq0NGDZHxcUgMUgwPU
lqzhA0UTK70kN0HrrhLQgaf7HUt5N3G5LlIAoW2SYuW+EXTSycclRG2A3leX53Ce
f9iXkklOdS5kuc6a3+BGu45+/izpDWJwa7EVAjDDh+qXwl26/zZBukj9iGfXYZWf
JO6JTqCLaUZXYPBrC9RDAEwq6La6WoWN883+FNUVfnjcdGI+e9hRfsP6jRsuHU9y
l+1DtGMziZe0w+pVEuqe/iQuPI3Hj+mfMsyhXTLXFxQggfs9UykVQ+b+l4o7MOFJ
ryGfR/LgAtLzT4R9jia+PfiGFlsZCcgPeuSp6zYaeIKOau7jaPJK/prJLJOMrayU
5RBsdNBxszVycVmaFEjtzlkzmX4plrNTU1xoOrHAQVIsmiseeemH0PmGal4EpWHq
Q3y4xF5nT1OKL3AAshO/wwuxEG6i9D7UES00IsvCSNTYAE4T/BdPZn3gKg8/Rnup
Ge5iuE/+BDpG2kNAeqQdAJ6BOq17ZGyA5MSGrleGQlhrZzJboDpU0SQu3eJhC76E
m/AYpyOg8CzYkM+YSc0z4N9j1OHQh1ckTH1hZe3i37MA82PJEOvIEpAAmzXUDaP5
bTbPlbhklJiOWQzybSVW
=6Fz7
-END PGP SIGNATURE-
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] Interview with Coverity

[Christian Heimes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Kristin Brennan from Coverity has asked me for an interview about
Python core development and how we are using Coverity Scan. Coverity
is planing to have a monthly series of interviews with open source
projects that use their service, for example
http://www.coverity.com/company/press-releases/read/coverity-introduces-monthly-spotlight-series-for-coverity-scan-open-source-projects

She has send me a list of questions up front. I like you to review and
comment on my preliminary answers, please.

Thanks,
Christian


Q: How many active developers do you have contributing to the project?

- - 174 according to http://hg.python.org/committers.txt

- - 152 according to
http://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300

- - about 60 active according to https://www.ohloh.net/p/python/

- - about 360 contributors agreements (513 - 152) according to
http://bugs.python.org/user?contrib_form=yes&%40action=search

- - about 1400 names in Misc/ACKS

Python Core Mentorship program and PyLadies have helped to attract new
contributors.


- ---
Q: Why do you think you are able to achieve high levels of quality? (
than liked size commercial projects)

Python has an established and well working workflow. The majority of
commits are accompanied by a ticket. Most bug fixes (except for
trivial ones) and all new features are reviewed by other developers
(Rietvield) before the patches are committed. Documentation updates,
changelog entries and unit tests are usually part of a patch, too.
Large features and modifications go through the PEP (Python
Enhancement Proposal) process.

CPython core development heavily relies on automatic tests. We are
using buildbot for continuous integration since at least 2006. About
40 buildbot instances to run 10k test cases on different of platforms
and architectures: Linux (multiple distributions), Windows, Mac, BSD,
even exotic operating systems like Solaris and AIX and hardware like
PPC, MIPS, Sparc and Alpha (Snakebite).

CPython uses time based releases not feature releases. New features
only land in the development branch, when they are stable and went
through our review process. We are not under pressure to add "cool
stuff" to increase our market share. Our goal is to provide a stable
and slowly evolving foundation for our community. Revolutionary pieces
of software are developed outside the core by other developers. Some
of them are later integrated into the core when they are deemed mature
and best practice.

Backward compatibility is also very important to us -- except when we
break it deliberately with Python 3. New features are never added to
patch level releases, too.

Most of Python is written in Python, too. It's much easier and less
errorprone to maintain Python code than C code. The rest of Python is
written in well structured ANSI C (C89) with a well designed C API and
a strong focus on POSIX.

- ---
Q: What is it about the developers on your program that you think
enables them to create high quality code?

All core committers are highly motivated and care deeply for Python.
Although we are split up across lots of countries, cultures and time
zones we are able to work together as a team very well ...

[any ideas?]


- ---
Q: What happens if you have a developer working on the project that
submits code doesn't meet quality expectations?

It rarely happens as most changes go through a thorough review process
before they are committed. Once in a while some issues slip through --
after all we are just humans. Since commits are tightly monitored such
issues are pointed in a matter of hours, even minutes. Either the
issue is sorted out as soon as possible or the commit is reverted.

Everybody is more careful in the vicinity of a new release, too.


- ---
Q: What sort of process do you follow to ensure high quality code?

Python has coding standards for C and Python code. Major chances to
through the PEP process, other chances go through a review process.
Stable APIs, ABIs, automated tests and continuous integration ... but
also tedious bike shedding discussions on the mailing list.

[repetition of stuff I said before ...]


- ---
Q:Do you have people in formal roles to ensure the quality of the code?

In theory Python has a hierarchy:

Guido (Benevolent Dictator for Life) > release manager > expert for
module or area of interested > core committer > contributor

In practice this hierarchy is never imposed upon somebody but rather
used as a tool to aid the development process. Every core committer is
responsible for her checkins and does her best to meet our demands in
quality. She also helps contributors to improve their patches and
teaches them Python's coding conventions and best practices. Experts
for a module or topic are often included in the discussion to get
their opinion and to benefit from their knowledge.


- ---
Q: Can you describe how development testing and the Coverity Scan
service fit

Re: [python-committers] SSH fingerprint

[Christian Heimes]

Am 25.03.2013 05:51, schrieb Jeffrey Yasskin:
> You missed that ECDSA != DSA.

Yeah, Elliptic Curve DSA is as secure as RSA while using much shorter
keys. ECDSA verification used to be much slower so you may want to
prefer RSA for short time connections like hg pull and push.

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

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

[Christian Heimes]

Am 25.12.2012 13:37, schrieb Nick Coghlan:
> I'm well and truly to the point of caring far more about the feelings
> of people who get frustrated trying to deal with his obtuseness
> (whether that arises deliberately or through genuine cluelessness)
> than I care about his feelings. He has the entire internet to play on,
> we don't have to allow him access to python.org controlled resources.

+1

He is so far beyond the point of political correctness and
respectability that I'm unable to find any words for his behavior in my
dictionary. His attitude hasn't improved, too. For example in bug
http://bugs.python.org/issue16689 he used an offensive title and
re-opened the ticket *twice* although it was closed by two different and
highly respectable core devs.

I hate to kick out people but I see no other way to deal with the issue
anymore. :(

Christian
___
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?

[Christian Heimes]

Am 19.08.2012 18:02, schrieb Brett Cannon:
> The link to their build tools is http://scan.coverity.com/self-build/ .
> So it looks like we have to give them the files to analyze now after we
> have built them with their tool chain on LInux.

Yes, that's what I'm talking about. It took me a while to figure out the
correct URL and my password, too. The new version of coverity doesn't
pull the changes automatically. Instead you have to compile the code
with a custom build system and provide a download link for the results:

Coverity Scan Self-Build - updated July 2012

Coverity build tool link is:

Linux-64 6.0.2
Linux-32 6.0.2

Downloading and building
Do once:

Download and extract the tarball

Add the bin directory to your path

Do for each build:

cd to your build directory
optional: Run any build steps that you don't want to analyze –
i.e. ./configure
cov-build --dir cov-int [BUILD CMD and ARGS]
Create a README file with your name, email, and project's name
tar czvf project.tgz README cov-int
Upload the project.tgz to your server

For your first build, after making the archive file available on a
server, send the URL for it to scan-ad...@coverity.com. Once we sort out
any issues with the archive processing, you will get project name, and
password to submit builds automatically whenever you like.
Submitting self-builds
Enter project name, password, email and download URL here:
http://scan.coverity.com/submit.html


http://scan.coverity.com/self-build/6.0.2/cov-analysis-linux64-6.0.2.tar.gz
http://scan.coverity.com/self-build/6.0.2/cov-analysis-linux32-6.0.2.tar.gz


I've tried to upload my build of Python's py3k head but the system
doesn't recognize my password for the upload process. I guess we need to
get a different password for the upload process. Or you could try your
login data. Perhaps I don't have the necessary permissions. My build is
available at http://dl.dropbox.com/u/19557108/project.tgz

Christian
___
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?

[Christian Heimes]

Am 18.08.2012 15:08, schrieb Stefan Krah:
> Christian Heimes  wrote:
>> Yup, my login still works. I can send you a CSV or XML report if you like.
> 
> Thanks, got the CSV!
> 
> If anyone has the possibility to create new accounts, I would like to apply
> for one.

Who usually uploads the necessary files to coverity? The current files
are rather old (patchlevel.h says 3.3.0a0). I was able to create the
report files but the files must be uploaded to a registered location.

Christian

___
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?

[Christian Heimes]

Am 18.08.2012 11:53, schrieb Stefan Krah:
> Antoine Pitrou  wrote:
>> Besides, if the coverity results are private and limited to a couple of
>> core devs, I don't think other sprinters will benefit a lot from such
>> "education". Or do you have something particular in mind?
> 
> What is the status of the scans? Does anyone have access by now? For example,
> I'm curious to see the results for Modules/_decimal/*, 
> Modules/_decimal/libmpdec/*
> and Objects/memoryobject.c.

Yup, my login still works. I can send you a CSV or XML report if you like.

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

Re: [python-committers] Why r69846 is not merged to "release26-maint"?

[Christian Heimes]

Georg Brandl schrieb:
> David Goodger schrieb:
>> On Thu, Jul 2, 2009 at 14:56, R. David Murray wrote:
>>> I can see it now...the TV and movie track at PyCon 2010,
>>> with attendance mandatory for anyone wanting to participate
>>> in the Core sprint...
>> We actually had a room or two for evening videos at a PyCon (both?) in
>> Dallas. Somebody brought the boxed set of the Flying Circus show and
>> had it running. I fondly recall processing email while chuckling...
>>
>> It wasn't very well attended though.
> 
> There is a slight chance that EuroPython 2011 might come to Germany --
> in this case, some kind of Monty Python showing must be arranged.  As
> you all know, we really can use the education.

Georg, I suggest that you get a head start by watching these youtube
clips: http://www.youtube.com/user/MontyPython

Are there already plans in which city EP11 might be hosted? You know
Spamalot is playing in Cologne, too. :)

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

Re: [python-committers] Why r69846 is not merged to"release26-maint"?

[Christian Heimes]

Barry Warsaw wrote:
> I will announce this to py-list, py-ann, and update the 3.0 download pages.
> 
> There will be no 3.0.2.

+1 for your decision.

Are there any known incompatibilities that could break a Python 3.0
script on 3.1?
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] svnmerge

[Christian Heimes]

Antoine Pitrou schrieb:
> Le dimanche 01 mars 2009 à 21:08 +0100, "Martin v. Löwis" a écrit :
>> I meant that as a relative qualification indeed (merging a single
>> revision specified on the command line as opposed to merging all
>> available versions).
>>
>> I just measured merging r70081, and it took 42s.
> 
> After the merge from io-c to py3k, where svnmerge seems to have
> "forgotten" a couple of changes which I have had to fix manually, I want
> to say that svnmerge has more than simply performance issues... ;-)

I ran into similar trouble during the merge of the long running math
branch. After two failed attempts I decided to merge the changes
manually. I couldn't figure out why svnmerge was failing because I
hadn't had enough spare time.

Christian
___
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

[Christian Heimes]

Nick Coghlan schrieb:
> Georg Brandl wrote:
>> It doesn't only *feel* slow, it *is* slow.  And not only compared to merging
>> with a DVCS, which doesn't need network.  Half a minute to merge a three-line
>> change is not productive.
> 
> Don't forget that *blocking* a revision with svnmerge seems to take
> nearly as long as actually merging it does (the only part that seems to
> save time is the fact that you don't need to build and/or run the test
> suite afterwards).

Even worse, svnmerge makes concurrent merging impossible. You get a
conflict every time two people are merging the same time. In the Python
project we don't see the issue often but at work I could hear a
frustrated scream at least once a day. We've started a "manual merge
lock" by yelling "merge" from one developer room to the other.

Totally annoying, though.

Christian
___
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

[Christian Heimes]

Nick Coghlan wrote:
> Bob Ippolito wrote:
>> I have more or less the same opinion as Guido regarding svn merge. It
>> sucks. We bump up against problems with svn merge tracking on a
>> regular basis at work. We'd have switched to a DVCS by now if it
>> wasn't for tool support (trac mostly) and the fact that we use a lot
>> of svn:externals in our repository.
> 
> We have a few of those (svn:externals) as well... Brett, another
> question for your DVCS champions!

As far as I can recall the PEP doesn't cover metadata at all. Subversion
supports metadata in properties via svn prop[set|get|del]. Do the DVCS
support properties, too? What about svn:ignore (ignore files and
directories via glob style patterns), svn:keywords (expand keywords like
$ID$), svn:executable (chmods a file a+x) and svn:eol-style (forces a
line ending style).

Christian

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

Re: [python-committers] I've got a surprise for you!

[Christian Heimes]

Trent Nelson schrieb:
> Catchy subject eh?  Unless, of course, you've seen Forgetting Sarah
> Marshall, in which case, it's probably a tad disturbing.
> 
> Nevertheless, I do have a surprise for everyone.  I spent a lot of
> time early last year trying to keep the buildbots green, especially
> the x64 Windows ones.  This was quite enjoyable, at least initially.

Wow! :)
I can barely find the words to express my feelings. You did an amazing
job! Thank you very, *VERY* much!

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

Re: [python-committers] Luke Kenneth

[Christian Heimes]

Guido van Rossum schrieb:
> 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?

You are seeing it perfectly right. I'm astonished that nobody has
reacted and kicked him from the list so far. I like to establish a
police that comparing something to the Nazi regime has the same effect
as using the word Jehova. Who likes to throw the first stone? :)

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

Re: [python-committers] trying again...

[Christian Heimes]

Barry Warsaw wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 6, 2008, at 8:27 PM, Barry Warsaw wrote:


3.0 branch frozen.  Ping me on irc if you need to make commits.


No go, the docs are still broken.  I've re-opened issue 4266 and will 
try to ping Georg in my tomorrow morning.


I've a workaround for the problem. It removes the seealso tag that is 
responsible for the error.


svn diff
Index: Doc/using/cmdline.rst
===
--- Doc/using/cmdline.rst   (Revision 67134)
+++ Doc/using/cmdline.rst   (Arbeitskopie)
@@ -135,10 +135,7 @@
 an empty string (``""``) and the current directory will be added to the
 start of :data:`sys.path`.

-   .. seealso::
-  :ref:`tut-invoking`

-
 Generic options
 ~~~

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

Re: [python-committers] broken arm

[Christian Heimes]

Jesus Cea wrote:

I just have broken my left arm last saturday (sliding swimming pools are
dangerous :)). I will be barely online for the next 6 weeks. I will try
to keep email backlog under control, but single-hand typing is a nightmare.


Take the opportunity and read some good books! :] And get well soon.

Christian

PS: Who was talking about a single point of failure a few days ago? ...
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] python 3.0 compilation warning in Objects/stringlib/find.h

[Christian Heimes]

Amaury Forgeot d'Arc wrote:

Hello,

r65977 was not correctly merged into py3k; I get the following
compilation warning:

Objects/stringlib/find.h:93:36: warning: extra tokens at end of #ifdef directive

And indeed, the line

#ifdef STRINGLIB_WANT_CONTAINS_OBJ && !defined(FROM_BYTEARRAY)

does not seem correct. I suppose the "#ifdef" could be replaced by
"#if defined",
but I'm not sure to understand the code. The symbol seems not to be
defined anywhere...


At first I thought it's my fault. I added the FROM_BYTEARRAY macro to 
stringlib/find.h and bytearrayobject.c a while ago. It was necessary in 
order to get rid of a compiler warning in bytearrayobject.c. However I 
added the macro only to the trunk.


The code was ported to the py3k branch although it isn't necessary. You 
can safely remove the check for FROM_BYTEARRAY.


Christian


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

Re: [python-committers] ubuntu release plan

[Christian Heimes]

Anthony Baxter wrote:

What would this professionalisation get us that we don't have now? As
far as I can see, the biggest hole at the moment (as always) is with
people to trawl the tracker and triage bug reports and patches.


It would get us one or some developers who can work 8+ hours a day, five 
days a week. A paid developer could do all crummy jobs like closing 
bugs. A paid release manager could dedicate more time to take care of 
things. I strongly believe that two full time developers can make a 
difference by providing a better infrastructure for the rest of us.


I blindly assume that non of us is going to say "Give me bucks or I 
won't code any more". But our economy is going through a recession, 
everything is getting more expensive by the day. A constant income would 
allow some guys to code without them worrying about money.
For example we have several talented students in our midst. Let's tap 
into their potential by hiring them. They could use their talent to our 
benefits instead of earning money through internships or side jobs.


Christian

PS: No, I'm not trying to get me a paid job here. I've already got a 
great and well paid one. *g*

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

Re: [python-committers] PQM?

[Christian Heimes]

Barry Warsaw wrote:
Let me take this opportunity to explicitly say that I'm not /blaming/ 
anybody for this.  I consider the problems we had with the module an 
indication of a systemic, team-wide deficiency.  I greatly appreciate 
you (and others) working so hard to land it and make it work.


Hey! Somebody is reading my mind here ... By any chance are you 
telepathic? *g*

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

Re: [python-committers] ubuntu release plan

[Christian Heimes]

Antoine Pitrou wrote:

Ubuntu's sophisticated release plan is certainly justified by its
business model, and the desire to both appeal to the open source people
and the corporate people without creating two different distributions.

I don't think Python has the same business requirements (neither does it
have marketing and commercial teams), and having differentiated releases
sounds like unwarranted complication.


IMHO the PSF and Python core development crew doesn't have a business 
plan at all. By business plan I'm referring to making money with Python 
directly. As far as I know most core developers are working on Python 
beause it's fun. Some developers like Guido are paid by their employers 
to work on Python as part of their job.


Just a crazy idea ... Maybe it's time to make the next step toward 
professionalizing Python. Python is more and more becoming important for 
companies. They have to rely upon a stable and solid Python interpreter. 
 Perhaps some companies are willing to pay the PSF. In return the PSF 
could hire some developer to work on Python full time. A couple of 
months ago one well known core developer expressed his interest in a 
paid job. A crew of three to four full time developers could make a huge 
difference.



Just my two non-Canonical cents of course!


Nice pun :)

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

Re: [python-committers] PQM?

[Christian Heimes]

Barry Warsaw wrote:
Unfortunately, they're not being solved without PQM either!  Really, 
we've had to delay releases several times because the branches were 
broken across multiple operating systems.  Pleading on the mailing lists 
doesn't help.  Hanging out on irc doesn't help.  Having Benjamin, Georg, 
and others kicking ass on #python-dev the day of a release, is great, 
but it's also asking a lot of them.


Yeah, I concur with you. I've also done my fair share of nights 
dragging, kicking and punching the code into shape for a release. It 
sucks and it's sending my coffee bill sky high.


By the way the guys are totally awesome, dude. :)

That's what branches are for.  I really strongly feel that the mainlines 
(by which I mean the branches we cut releases from) should always be in 
a releasable state.  We should never be committing broken tests to these 
mainlines.  If you spot a problem you can't fix, create a branch and 
commit the broken test there, and ask for help with that branch.  The 
mainline isn't (IMHO) the place for that.


You're right that it will slow us down, but only on the mainline.  
That's a good thing, especially if it buys you high quality.


Sticking to our own rules would also buy us quality ... Let's not add 
new features to our code base during the beta phase, please. Although 
the addition of multiprocessing had some merit, we shouldn't to the same 
mistake twice.


Perhaps we could adopt a release plan similar to Ubuntu. They have 
releases with cool, new and bleeding edge stuff followed by a release 
that focuses on stability and long term support. Python 2.6 and 
especially 3.0 are releases with new features. What do you think about 
focusing on stability and long time support for 2.7 and 3.1? 2.7 might 
be the last version of the 2.x series and we sure gonna have to fix lots 
of issues in the 3.x series until it's matured.


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

Re: [python-committers] PQM?

[Christian Heimes]

Guido van Rossum wrote:

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


Yeah, I had an acute case of burnout syndrome. I tried to do far too 
many things in parallel. I prescribed myself to focus on the most 
important tasks like my new apartment and my job first. Heck, some of my 
stuff is still in boxes! Relocating is sooo time consuming.



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).


Our buildbot system has another issue. It's sending out far too many 
mails with too many text. The s/n ratio is bad which makes it tedious to 
study the reports. I'd prefer a summary once a day which lists the 
failing build bots, platforms and tests. Add some links to extensive 
test output, revisions and authors and you'd get a short report instead 
of ten extensive reports.



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.


I agree!

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

Re: [python-committers] PQM?

[Christian Heimes]

Barry Warsaw wrote:
I think this is a case where PQM might have helped.  Assuming the 
build/test would uncover these subtle bugs, the multiprocessing code 
would not have landed.  You would then probably publish a branch with d t
those (failing) changes and rally the help you needed to fix those 
problems.  Then you'd try to land it again.


The workflow would have likely been very similar to what happened for 
this code, except that it would be happening on a branch, not on the 
mainline.  Maybe no one would have been motivated enough to get them 
working if they weren't breaking mainline.  The tradeoff is instability 
in the mainline and uncertainty as to whether the mainline is of high 
enough quality to release.


I suggest that we should use branches to a greater extend. New features 
or updates of existing code should happen on a branch. A branch must not 
be merged until it's tested on all major platforms (Linux i386, Linux 
AMD64, Mac OS X and Win32) and peer reviewed by another developer.


During my time as a Zope and Plone developer and at various XP sprints 
I've utilized the branch development and peer reviewing workflow with 
great success. I assume the majority of Python developers don't do 
branches because it's an expensive and annoying operation with svn. Well 
branching isn't so annoying but merging and keeping a branch up to date 
definitely is. Once we have a VCS with cheap branching and easy merging 
we should switch to branched development.


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

Re: [python-committers] PQM?

[Christian Heimes]

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.

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

Re: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for commit privs.

[Christian Heimes]

Trent Nelson wrote:

What do people think about making Hirokazu Yamamoto a committer?  I rarely see 
any mailing list posts from him, but he sure makes up for it in terms of 
patches submitted to the issue tracker.  As far as I can tell (I've noticed his 
regular involvement via patches and whatnot for well over a year), he's a 
pretty switched on guy with a lot of Windows experience -- every time trunk 
fails to build with vc6/7/8, for example, he's got patches lined up.


+1 from me

I like to nominate Hirokazu as maintainer of the VC 6 to VS 8 (2005) 
build directories. He is pretty much the only tester of the VC 6 and VS 
7 build systems - and one of the few that care about the old versions of 
MS compilers, too.


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