It's about nine days from now. I expect to tag the release late next
week. So if you're doing any major brain surgery, please finish it up
in the next week or so.
Your mildly anxious release manager,
p.s. Anybody have contact information for Jim Hugunin? He left Google
back in May and has dropped off the face of the internet. I want to
interview him for my podcast.
I thought I'd send this to postmaster and -committers first. If I don't get
enough responses, I'll open it up to python-dev and python-list next. (But we
know and trust you guys already :).
Neither Sjoerd nor I read python-list and yet we're the list owners. It's
time to solicit new list owners and/or moderators, ideally someones who have
more of a vested interest in python-list than we do.
Please let me know if you would like to pitch in and help moderate
python-list. Once I get a good collection of volunteers, I'll reset the list
password and mail the new one to you.
I don't see any entries in the "Changes" column when I look at a
filtered BuildBot waterfall like
Is that expected? A bug in our BuildBot setup? A bug in BuildBot itself?
(This is in Firefox 22 on Fedora 18)
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE-----
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
She has send me a list of questions up front. I like you to review and
comment on my preliminary answers, please.
Q: How many active developers do you have contributing to the project?
- - 174 according to http://hg.python.org/committers.txt
- - 152 according to
- - about 60 active according to https://www.ohloh.net/p/python/
- - about 360 contributors agreements (513 - 152) according to
- - about 1400 names in Misc/ACKS
Python Core Mentorship program and PyLadies have helped to attract new
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 ...
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 fits into your release process?
Coverity comes into play when the code base has stabilized and a new
minor release is approaching its release candidate phase. Coverity is
especially useful to find issues in unlikely code paths like error
case that are not reached under ordinary circumstances. A stable code
base makes it easier to find and fix the problematic code segments.
Recently I went through all untriaged Coverity issues and either
fixed, closed or triaged them all. For the future I'm planing to fix
or report issues as they are detected. Of course it depends on my free
Q: What tools do you use, besides Coverity, and how do they impact
your ability to deliver high quality code
- - Roundup issue tracker
- - Rietveld code review
- - buildbot for CI
- - fusil for fuzzing tests and pyfailmalloc to add random malloc()
failures (both created by Python core dev Victor Stinner)
- - GCC's gcov
- - clang analyzer (Brett ?)
- - instrumented Python builds (--with-pydebug) with extra checks,
asserts and reference leak checks
- - ...
Most tools are written in Python
Q: What challenges do you face with regard to maintaining high quality
code that are unique to open source and how do you overcome those
[Does anybody have an idea for a good answer?]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
On Mon, 15 Jul 2013 11:09:08 +0300, Michael Foord <michael(a)voidspace.org.uk> wrote:
> On 15 Jul 2013, at 11:05, "M.-A. Lemburg" <mal(a)python.org> wrote:
> > Who would be the one to contact for issues like these ?
> > The case is rather urgent, since the XSS can be used for stealing
> > session cookies on *.python.org.
> > The sorting by password issue is a more obscure one. Just removing
> > the "feature" to sort by password should be enough to solve it.
> Technically it's an infrastructure issue (cc'd), but fixing the code of roundup is hardly their domain.
> Ezio Melotti (cc'd) did a lot of work on the Python installation of roundup, so he may have a better idea.
> We have a security mailing list but that is mainly intended for security issues in the language:
> security(a)python.org <security(a)python.org>
The OP also emailed security (which I heard about via IRC, I'm not
on that list).
Ezio is a Roundup developer, so he is indeed the best person to look
at the XSS issue, since it is a Roundup problem and not specific to
the Tracker. I can take a look too but he is more knowledgeable
than I about roundup itself.
There is another problem which is specific to our tracker and which is the
bigger issue right at the moment. We have a 'nobody' user with a blank
password and Developer privileges.
I'm about to go out, so I don't want to make a change that might break
something right this moment, but anyone with the Coordinator role
could take this on if they want to do it right now: remove either the
Developer role, or both roles, from that user and see what happens.
I suspect that user should not exist at all, but I don't know for sure.
On Mon, 15 Jul 2013 08:22:40 -0400, Donald Stufft <donald(a)stufft.io> wrote:
> So I was able to log in to the "nobody" account without a password
> (Why is this even possible?). It gave me powers to edit users and some
> other shit. I added a password to the nobody account since these lists
> are publicly available and if I can get into that user so can others.
Ah, I didn't realize you could edit users (I thought that was
Coordinator role) or I would have changed the password myself.
> I will make the password available to whoever is in charge, (Or they
> can just change the password themselves I don't care).
I think the user should just be retired. My guess is that it dates from
a time when we were less worried about bad actors coming in and trashing
things just for the fun of it. What I don't know is if there is some
script somewhere depending on it being a valid user. For now, I've
removed its access roles, and we'll see if anything breaks.