I created a new pull request to add a forgotten news entry, and now it's going through all the pre-checks, etc.
I seem to recall we could add a "trivial" tag to an issue to skip those. Is that still true, and if so, how?
I want to propose granting commit privileges to Nathaniel J. Smith.
He's interested in the idea of becoming a core developer, and given
the quality of his contributionsI think he won't need any extensive
mentoring (although I'll be happy to assist Nathaniel in the
Nathaniel has been a prolific PEP author:
* Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
PEP 533, PEP 568;
* Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
(accepted), PEP 522.
* Many PEPs mention his name in acknowledgements.
He also has a few sufficiently complex patches committed, some of
which touch complex areas like ceval loop and signals handling:
* bpo-32591: Add native coroutine origin tracking
* bpo-30579: Allow TracebackType creation and tb_next mutation from Python
* bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
* bpo-30039: Don't run signal handlers while resuming a yield from stack
* bpo-30038: fix race condition in signal delivery + wakeup fd
He's been very active on python-dev, python-ideas, bugs.python.org and
github. Here's an example where Nathaniel's research helped us to make
a right decision to fix a broken socket object API:
He helped me quite a bit with the design of PEP 550 and PEP 567, and
he's doing some interesting work in the async/await area.
So... let's make it happen? :)
I identified some active contributors and I would like to offer them
to get the "bug triage" permission. What's the requirements to give
such permissions to someone?
On my "Different stages of core developers" "lader", it's the 3rd
Requirements to become a core developer (get the "commit bit") are now
It would be nice to write down requirements to get the bug triage permission.
IMHO the requirements are quite low:
* at least one commit merged in Python
* signed the CLA
* be nice and respectful
* don't close a bug if it's not well understood to not "loose"
information (closed bugs are ignored in search by default, and hidden
from the main page).
Did it happen in the past that we removed the bug triage permission to
someone who abused this power?
Maybe we can give some guide lines on how to behave on the bug tracker?
Responsability for bug tracker:
* Request more information if a report is incomplete
* Ping original reporters if they don't reply
* Adjust Python version, component, bug type, etc.
* Rewrite the issue title if needed
* Close duplicated bugs as DUPLICATE
* Close irrevelant bugs as NOTABUG
The exact behaviour on the bug tracker is not specified. For example,
when someone asks for help on code, I close the issue and suggest to
use a different forum to get help, without giving examples of forums
(since I simply don't know them :-)).
When the reported issue described a legit Python behaviour, I try to
explain the rationale of the behaviour before closing the issue as
"not a bug".
Sometimes I'm just tired of the 4th bug report on "floating point
rouding issue" and just give the link to the FAQ without explaining
Devguide §Helping Triage Issues
2018-01-25 0:29 GMT+01:00 Eric V. Smith <eric(a)trueblade.com>:
> +1. I actually thought [Nathaniel Smith] was a committer already.
By the way, if you notice an active contributor is good candidate to
become a core dev in the long term, you may start the process that I
My proposed process is made of small steps to build a trust
relationship and to train contributors until they produce
For you, the main requirement is time, be available to review changes
and answers to questions by email :-)
Last weeks, I looked at contributors who got the most commits merged
into master in the last 6 months. That's how I selected Cheryl
Sabella, Sanyam Khurana and Pablo Galindo Salgado.
I also asked two contributors if they would like to become core, but
they declined my offer.
I added a new section in my process document: § "Becoming A Core
Developer Is Not a Goal". I'm not sure that it's the best title ever.
CPython isn't the easiest place to start. The development process is
rather enterprisy with long release cycles (release every 18 months)
and rigid backwards compatibility policy. CPython also support many
different platforms and CPU architectures.
Are you sure that CPython itself is the best project for you?
Depending on your interests and skills, you may enjoy better to
contribute to another Python project with lower backward compatibility
constraints and a faster release cycle.
Being a CPython core developer involves responsibilities and usually
requires a lot of time. Long-term commitment is also a major
expectation, even if it's not a strict requirement. Becoming a core
developer should not be seen as a recognition of a contributor work,
but more as a constraint :-) Merging a change implies becoming
responsible regressions, backward compatibility, security, etc. of
It is perfectly fine to contribute to CPython without being a core
developer. In most cases, not being able to merge your own work is not
a blocker issue.
I'm not sure about this sentence: "Becoming a core developer should
not be seen as a recognition of a contributor work, but more as a
constraint :-)". My intent is to discourage people who "want to become
a core dev" for the bad reasons (to become famous? I don't know
exactly) without understanding the expected responsibilities.
I plan to come back to python development (about time!) but I truly
hates git. I am experimenting with mercurial + hg-git extension and it
is quite usable (after the initial painfully slow clone time), but I am
having small quirks that I would like to iron out with a fellow more
experienced or also interested in this approach.
Anybody out there?.
If this is considered off-topic, please let me know.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
jabber / xmpp:email@example.com _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
what is the official way to checkout a tag for debugging? I did:
git checkout v3.6.0
This just worked in mercurial, but doing the above results in a
threadmodule.c:1355: multiple definition of `PyInit__thread'
I have three PRs for Python 3.5.5rc1:
I can't merge them because Travis CI is unhappy. All three CI tests
fail in the same way, reporting this error:
The command "pyenv global system 3.5" failed and exited with 1 during .
Since Travis CI is a "required check", Github won't let me merge the
PR. Yes I could manually merge the patches by hand but I'm hoping it
doesn't come to that.
I'm slipping 3.4.8rc1 because I prefer to do both releases at once.
I'm hoping this problem will be resolved quickly; if we only slip the
RCs by a day or two I won't slip the final releases (in about two weeks).
PLS SND HALP,