Mailman 3 July 2013 - python-committers

Reminder: Python 3.4 alpha 1 release is Saturday August 3
by Larry Hastings 03 Aug '13

03 Aug '13

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, //arry/ 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.

11 18

Re: [python-committers] python-list moderation flag
by Barry Warsaw 29 Jul '13

29 Jul '13

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. Cheers, -Barry

1 0

Changes column on filtered BuildBot waterfall views?
by Nick Coghlan 28 Jul '13

28 Jul '13

I don't see any entries in the "Changes" column when I look at a filtered BuildBot waterfall like http://buildbot.python.org/all/waterfall?category=3.x.stable Is that expected? A bug in our BuildBot setup? A bug in BuildBot itself? (This is in Firefox 22 on Fedora 18) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

Interview with Coverity
by Christian Heimes 18 Jul '13

18 Jul '13

-----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-mon… 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&@pa… - - 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 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 time... - --- 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 challenges? [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/ iQIcBAEBCAAGBQJR5y8AAAoJEMeIxMHUVQ1FjRYP/j9nhCk82JrBp8h3Sie9ryOx N2o5qX5xYWehjV7Y1iQXFK9s43VprB8xup6ZC09/1lwQKLjsnyk6QgLf9+RrDWin gaeG4CTwykuiASzU1xQJxdyj7YXDmGy/C5zIxpSNKVkLn7AwB/ob1+Tf7AAkeNHd z8C8xCihBYHgp8iY8k3Y7yuYpFuVr6+Qz8wtl/ubU76ys5IsPf5h0JxMfQh+oNpc +8TewXQsPnPlFvkdm9T0ecnAG7s6MCCqhEL/11kSx9LLKXEK6CtSnEEMgkWdDpmC bLeiM6UWs9hiimXKSnWEP/J3fXAFsq9M22jkmPDYSPIEtY0SoHHaHLdrb9uj0BUX jtM1c/I+gFeWO76RN6LJXqpMpoH8vGDeHnvP0jJbeMN+Ma6XSD01LD8hK0dPZ4lX H6p2VfoZCrj28XPLyClKLSryZ23kq1JHqxM6pOTYQEVUtmZLJlKkTn9GCIwZiLPd FRlzaZpmto/iCqfq2s9XSs9maddMUWbUrn+30MDvU+cl1nb+JKxNKF5nNxqc64tI xRUs+b819UmeMq8eQ82IVi4o1fkh+QMOqZO2hmZWwUR8j9S4SAYQGnbvYzHrAnrw JI9+xBm72z3e09cjHe2PZ3oG/hPCM9BargAmNEqYaI6hE0R1CTqbVenBAwGfWD2B 6Nu9Iki9skroWbo34rKX =hLXG -----END PGP SIGNATURE-----

5 4

Re: [python-committers] [Infrastructure] [Pydotorg] XSS security issue
by R. David Murray 16 Jul '13

16 Jul '13

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

3 3

IMPORTANT: Strip your repos if you pulled recently
by Benjamin Peterson 16 Jul '13

16 Jul '13

If you have c3a510b22218 in your repo, you will need to strip it like this $ hg strip c3a510b22218 (make sure to have the mq extension enabled) Sorry for the trouble. -- Regards, Benjamin

5 9

I would suggest not pushing or pulling from the repo
by Benjamin Peterson 15 Jul '13

15 Jul '13

I accidently pushed a merge from 3.3 to default in the "3.3" branch. I think I'm going to have to strip it. -- Regards, Benjamin

3 4

Re: [python-committers] [Infrastructure] [Pydotorg] XSS security issue
by R. David Murray 15 Jul '13

15 Jul '13

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

3 3