Hi,
Python 3.5 entered security fix only mode. Should we now remove the
"needs backport to 3.5" label? Other security only branches don't have
this label neither (3.3 and 3.4).
Victor
Hi,
Recently, I asked their opinion to a few core developers about
promoting some active contributors to core developers.
It seems like we have no clear rules to decide if a contributor can be
promoted or not. The problem is that sometimes, I am explicitly asked:
What are the steps to become a core developer? Well, I'm not sure why
some people really want to become core developers, but that's not
question here :-)
I started to list "responsabilities" (is it the correct word?) of a
core developer.
First of all, I like how Mariatta summarized a promotion (in an oral
discussion that we had). Becoming a core developer doesn't give
*power*, but *responsabilities*. (Sorry, I'm not sure about the exact
wording, maybe Mariatta can correct me here ;-))
I also see that some core developers are more conservative, want to
reduce the risk of regressions, while some others are more on the
"forgiveness" trend ("it's better to ask forgiveness than
permission"). I think that it's perfectly normal and expected to have
people on the two sides. The question is how to find a compromise in
the middle.
I identified the following CPython core developers responsabilities:
* Long term commitement. We someone lands a big chunk of code, we need
someone to maintain it for at least the next 2 years. Maybe for the
next 10 years. I think that some people sign with their blood to
maintain crappy code for their own life, but it's better to not
elaborate this part ;-)
* Review patches and pull requests. While we don't require not expect
newcomers to review, we expect that core developers dedicate a part of
their time on reviews.
* Know the CPython workflow. Be aware of the pre-commit and
post-commits CIs. How ideas are discussed. It's not only about writing
and pushing patches.
* For C developer: know CPython specific issues like reference leaks
and the garbage collector. We expect that a core developer write code
with no reference leak, right? ;-)
* Good quality patches: proposed changes are good (or almost good) at
the first iteration. I'm not sure about this point, but I know a few
other developers have this requiurement to promote someone.
* Pushing core means becoming responsible for this code. For
regressions, backward compatibility, security, etc.
* Something else?
I don't expect this list to be complete. A vote for a promotion is
always done on a case by case basis, mostly because it's really hard
to be ready on *all* expected points. The discussion is more to
estimate how far is the contributor in its learning, if it's enough,
if more learning is needed, or if mentoring is needed.
Maybe we should also formalize the mentoring for contributors
identified as potential core developers. It can be an explicit step in
the promotion process. Each last core developers who get promoted last
year get a mentor if I recall correctly. What do you think?
I started to write an article "What is a CPython core developer?"
which describes even more things:
https://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_co…
Victor
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…
Mariatta Wijaya
Hey everyone,
If you've been waiting on a recent subscription renewal, my apologies—I
dropped the ball on following up on some of them, but I'm getting things
back in order with another request for renewals now that a few more are
flowing in.
If you are currently expired or within a month or so of a renewal, please
send me the email address you use, your full name, and your mailing
address. We haven't always needed mailing address for renewals, but they
have been asking for it lately. If your expiration is a few months away,
they seem to prefer we don't get too far ahead so email me directly when
that time comes, or perhaps another one of these batches will match up.
If you've never had a subscription but would like one, please send me the
email address you use, your full name, and your mailing address. This will
give you access to Microsoft's Developer Network, which includes access to
things like Visual Studio and Windows licenses that we can use for working
on Python.
Thanks for everyone's work on Python!
Brian
Hi,
As part of maintaining miss-islington, I think it would be great if I could
see the GitHub webhook events for the CPython repo, just to make it easier
for me to debug problems. Sometimes miss-islington doesn't work as
expected, and the logs I get from heroku aren't too useful..
Not sure who in here can give me such access..
The webhook info is located in
https://github.com/python/cpython/settings/hooks and to me this is a 404
right now.
Thanks :)
Mariatta Wijaya
https://bugs.python.org/issue30085https://github.com/python/cpython/pull/1171
were submitted last April.
Raymond assigned PR to himself, reviewed it in May.
Contributor Sanket revised according to reviews, in my opinion
adequately. Repeated pings on both issue and PR have not been answered.
Can someone else merge this?
tjr
Hi,
Since today, it seems like the macOS task of a Travis CI job to
validate a pull request hangs the whole job.
Don't try to cancel the macOS job, or the whole job will be marked as
failed! ... even if macOS is in the "Allowed Failure" section. I don't
know the best way to "repair" such job. I use "restart job" which
restarts all tasks, even the completed *and successful* Linux and doc
jobs.
I have PRs waiting for longer than 2 hours for Travis CI. The macOS
job is seen as "queued".
Yesterday, it was possible to merge a PR even if the macOS job was
still queued (no started).
I never wait for macOS, since, as I wrote, it can take longer than 1
hour. Moreover, macOS failures are not reported to the GitHub UI :-(
(Hum, in fact, I'm not sure about that.)
Maybe we should remove the pre-commit macOS task from the Travis CI
config to focus on post-commit macOS buildbots? If we remove it,
should we remove it from 2.7, 3.6 and master branches?
We have 3 macOS buildbots:
* x86 Tiger 3.x
* x86-64 El Capitan 3.x
* x86-64 Sierra 3.x
All three are currently green ;-)
In the last 3 months, the macOS task of Travis CI caused multiple issues :-/
Victor
Hi,
Before the GitHub era, in the old "Mercurial era", the unwritten rule
was to not merge a patch written by a developer who has the commit
bit, to not "steal" his/her work. The old workflow (patches attached
to the bug tracker) didn't allow to easily keep the author. You had to
find the author email and full name and specify it manually.
Moreover, there was a written rule of using the name of the developer
who actually pushed the commit, so the commiters took the
responsability of any regression (reminder the old era with no
pre-commit CI? ;-)).
In the new Git era, the author and committer *can* be two different
people. Examples with "git log --pretty=full":
commit 9abee722d448c1c00c7d4e11ce242ec7b13e5c49
Author: Victor Stinner <victor.stinner(a)gmail.com>
Commit: GitHub <noreply(a)github.com>
commit 8f51bb436f8adfd139cad046b91cd462c7f27f6c (tag: v3.7.0a1)
Author: Ned Deily <nad(a)python.org>
Commit: Ned Deily <nad(a)python.org>
commit 9b47af65375fab9318e88ccb061394a36c8c6c33
Author: svelankar <17737361+svelankar(a)users.noreply.github.com>
Commit: Raymond Hettinger <rhettinger(a)users.noreply.github.com>
My question is: is someone opposed that a core developer clicks on the
[Merge] button for a PR proposed by a different core developer?
IMHO having a committer different than the author is valuable since
the responsability is now shared by two developers instead of single
one. It's similar to the "Signed-Off" tags used by the Linux kernel,
but the list is limited to a single Signed-Off :-) Well, the committer
is usually seen as the most reponsible, but now we can complain to the
author as well *if needed* :-D
Victor
The Python build factories have been busy the last several weeks preparing
our fall lineup of releases. Today we are happy to announce three
additions: 3.6.3rc1, 3.7.0a1, and 3.3.7 final, which join last weekend's
2.7.14 and last month's 3.5.4 bug-fix releases and 3.4.7 security-fix
update (https://www.python.org/downloads/).
1. Python 3.6.3rc1 is the first release candidate for Python 3.6.3, the next
maintenance release of Python 3.6. While 3.6.3rc1 is a preview release and,
thus, not intended for production environments, we encourage you to explore
it and provide feedback via the Python bug tracker (https://bugs.python.org).
3.6.3 is planned for final release on 2017-10-02 with the next maintenance
release expected to follow in about 3 months. You can find Python 3.6.3rc1
and more information here:
https://www.python.org/downloads/release/python-363rc1/
2. Python 3.7.0a1 is the first of four planned alpha releases of Python 3.7,
the next feature release of Python. During the alpha phase, Python 3.7
remains under heavy development: additional features will be added
and existing features may be modified or deleted. Please keep in mind
that this is a preview release and its use is not recommended for
production environments. The next preview release, 3.6.0a2, is planned
for 2017-10-16. You can find Python 3.7.0a1 and more information here:
https://www.python.org/downloads/release/python-370a1/
3. Python 3.3.7 is also now available. It is a security-fix source-only
release and is expected to be the final release of any kind for Python
3.3.x before it reaches end-of-life status on 2017-09-29, five years after
its initial release. Because 3.3.x has long been in security-fix mode,
3.3.7 may no longer build correctly on all current operating system
releases and some tests may fail. If you are still using Python 3.3.x,
we **strongly** encourage you to upgrade now to a more recent, fully
supported version of Python 3. You can find Python 3.3.7 here:
https://www.python.org/downloads/release/python-337/
--
Ned Deily
nad(a)python.org -- []
Lots of releases coming up soon!
2017-09-16:
- Python 2.7.14 final release
2017-09-18 1200 UTC cutoff:
- Python 3.6.3 rc1
- Python 3.3.7 final release (following by retirement)
If you know of any issues that you feel need to be addressed in these releases, please make sure there is an open issue on the bug tracker set to "release blocker".
Also on 2017-09-18:
- Python 3.7.0 alpha 1
This will be the first preview snapshot of 3.7.0. It's still very early in the development cycle for 3.7. The main purpose of early alpha releases is to exercise the build and release process and to make it easier for Windows and Macs users to help test. Many new features and build changes are yet to appear in subsequent releases prior to feature code cutoff on 2018-01-29 at 3.7.0b1.
Thanks for your help!
--Ned
--
Ned Deily
nad(a)python.org -- []