Re: [Python-Dev] update on 2.7.4
Le Sun, 3 Feb 2013 19:11:36 -0500, Benjamin Peterson a écrit : > As you may have noticed, no 2.7.4 rc has been created yet. Yesterday, > the buildbots were all red, and release blocker issues had to be dealt > with. Today, I was not as availabIe and people were fixing > important-looking crashers. In general, there seems to have been a lot > more last-minute scrambling around than usual for a bugfix release. I don't know for others, but I had forgotten you were going to do a release. Sorry. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Mon, Feb 4, 2013 at 2:01 AM, Vinay Sajip wrote: > David Cournapeau gmail.com> writes: > >> You are putting the words out of the context in which those were >> written: it is stated that the focus is on the general architecture > > OK, no offence was meant. Thanks for the clarification. No worries, none taken :) David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] update on 2.7.4
Am 04.02.2013 01:11, schrieb Benjamin Peterson: > As you may have noticed, no 2.7.4 rc has been created yet. Yesterday, > the buildbots were all red, and release blocker issues had to be dealt > with. Today, I was not as availabIe and people were fixing > important-looking crashers. In general, there seems to have been a lot > more last-minute scrambling around than usual for a bugfix release. > > I'm afraid I'm still going to have to delay longer to see if we can > get a few security patches in. It could be next week. FWIW, the same goes for 3.2.4. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interested in GSoC 2013
On Sun, Feb 3, 2013 at 8:50 PM, Gregory P. Smith wrote: > First, welcome to Python. > > For people just starting out contributing we have setup a core-mentorship > mailing list ideally suited for this type of question. > http://mail.python.org/mailman/listinfo/core-mentorship > > general tip: look for open issues marked with the 'easy' on > bugs.python.org. > Actually there is an entire section to the devguide dedicated to helping you find something to do: http://docs.python.org/devguide/#contributing. Handling "easy" issues are part of the advanced section. =) -Brett > > > On Sun, Feb 3, 2013 at 12:51 PM, Jainit Purohit wrote: > >> Hi, >> >> >> I'm Jainit and I'm planning to apply for GSoC 2013 >> for the PSF. I was also part of GSoC 2012 in interface ecology lab, Texas >> A&M university. I just gone though Python developer's guide and how to >> become core contributor document. And I just compiled CPython on my >> machine. Since I'm new to this community, Can anyone assign me some >> task/issues/bug to work on to get the better idea of how things works. I >> would also like to know if any of you have any ideas which can be >> implemented this summer. >> >> >> Thanks!, >> >> Jainit >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org >> >> > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] update on 2.7.4
2013/2/3 Eli Bendersky : > > On Sun, Feb 3, 2013 at 4:11 PM, Benjamin Peterson > wrote: >> >> As you may have noticed, no 2.7.4 rc has been created yet. Yesterday, >> the buildbots were all red, and release blocker issues had to be dealt >> with. Today, I was not as availabIe and people were fixing >> important-looking crashers. In general, there seems to have been a lot >> more last-minute scrambling around than usual for a bugfix release. >> >> I'm afraid I'm still going to have to delay longer to see if we can >> get a few security patches in. It could be next week. > > > Thanks for the update, Benjamin. Given the recent discussions and events, I > would feel even safer if more than a week passed. I don't see how waiting a > bit longer is going to hurt anyone. At this point in 2.7's life, stability > is perhaps the most important thing. > > Perhaps this is the right time to specifically ask all contributors to > consider what may be blocking such a release - any bugs you recall seeing > that appear important and must be fixed? Friendly reminder: Please set such bugs to the "release blocker" priority. Otherwise, I will not see them. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL delegation for PEP 426 + distutils freeze
On 03.02.2013 19:33, Éric Araujo wrote: >> I vote for removing the "distutils is frozen" principle. > I’ve also been thinking about that. There have been two exceptions to > the freeze, for ABI flags in extension module names and for pycache > directories. When the stable ABI was added and MvL wanted to change > distutils (I don’t know to do what exactly), Tarek stood firm on the > freeze and asked for any improvement to go into distutils2, and after > MvL said that he would not contibute to an outside project, we merged d2 > into the stdlib. Namespace packages did not impact distutils either. > Now that we’ve removed packaging from the stdlib, we have two Python > features that are not supported in the standard packaging system, and I > agree that it is a bad thing for our users. > > I’d like to propose a reformulation of the freeze: > - refactorings for the sake of cleanup are still shunned > - fixes to really old bugs that have become the expected behavior are > still avoided > - fixes to follow OS changes are still allowed (we’ve had a number for > Debian multiarch, Apple moving stuff around, Windows manifest options > changes) > - support for Python evolutions that involve totally new code, commands > or setup parameters are now possible (this enables stable API support > as well as a new bdist format) > - behavior changes to track Python behavior changes are now possible > (this enables recognizing namespace packages, unless we decide they > need a new setup parameter) > > We’ll probably need to talk this over at PyCon (FYI I won’t be at the > language summit but I’ll take part in the packaging mini-summit planned > thanks to Nick). +1 on lifting the freeze from me. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 04 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
Am 03.02.2013 22:20, schrieb Gregory P. Smith: > On Thu, Jan 31, 2013 at 11:14 PM, Antoine Pitrou wrote: > >> On Fri, 1 Feb 2013 11:00:24 +1000 >> Nick Coghlan wrote: >>> On Fri, Feb 1, 2013 at 9:50 AM, Antoine Pitrou >> wrote: On Thu, 31 Jan 2013 23:52:27 +0100 (CET) matthias.klose wrote: > http://hg.python.org/cpython/rev/8ee6d96a1019 > changeset: 81859:8ee6d96a1019 > branch: 2.7 > parent: 81855:df9f8feb7444 > user:d...@python.org > date:Thu Jan 31 23:52:03 2013 +0100 > summary: > - Issue #17086: Backport the patches from the 3.3 branch to >> cross-build > the package. You aren't supposed to add new features to bugfix branches. Did you have a specific reason to do this? >>> >>> One of the reasons for the long maintenance period on 2.7 is to keep >>> it building as the underlying platforms change. With the rise of ARM >>> systems, being able to reliably cross-build Python 2.7 for ARM from an >>> x86_64 system is fairly important. >> >> I would like to see a better argument for this. The rise of ARM systems >> is the rise of ARM systems powerful enough to build Python without >> cross-compiling (which is why we *now* have ARM buildbots). >> The very small ARM systems which need cross-compiling have existed for >> decades. >> > > It is quite common for developers to build a single code base on a single > workstation targeting a plethora of platforms all at once. Requiring native > systems with self hosting tool-chains for builds is a non-starter as those > often don't exist. Making Python 2.7's configure+makefiles easier to cross > compile out of the box is a good thing. > > Side note: we really need a cross compiling build-bot host + target system > or we'll inevitably break this. > > >>> That said, as a procedural point for build related new features in >>> 2.7, I agree they should be proposed, with an explicit rationale, on >>> python-dev before proceeding with the commit. >> >> I think this huge changeset should be reverted. It's a complete failure >> in terms of procedure and following the rules. "Just because it can be >> useful" is not a good enough reason to violate our release model >> without even asking. >> > > That's up to the 2.7 release manager. Yes, this could have been done > better by asking first. But IMNSHO I'd prefer to see it stay in. I filed Issue #17086, and got feedback from the release manager, which I maybe interpreted too easily as not objecting. And it looked like a nice opportunity to get this into a release (hoping not to listen to another PyCon talk how to hack cross-builds). Even for the trunk, getting feed-back for cross-build related issues is difficult. Maybe reviewers are turned off by impolite comments in some of the cross-build related issues in the bug tracker, but that doesn't explain that you don't get feedback for most of the cross-build issues. So what I do understand, build-related issues like an arm64 or mingw32 port are ok for 2.7, if they are stable on the trunk, and communicated on python-dev? I'll see that I setup a cross buildd building in a cross-build environment and testing in a chroot with qemu installed. I hope that the buildd setup is able to support this. Talking about the release model, yes I think there are some issues: - the 2.7 branch is the only branch which doesn't have expected release dates on the calendar. And from a distributor/vendor point of view, I think yearly releases are too seldom. Such a release could end up only up to 24 months later in a (linux) distribution. - there were way too may regressions checked in on at least the 2.7 branch. Is it just our vcs merge model that we first have to check in on the branches, and then merge to the trunk? Afaics python is the only project to have such an approach. Others have trunk first, maybe with immediate backport, maybe with later backport. Matthias PS: Antoine: Please CC the committer for such emails. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
On 2/4/2013 3:04 PM, Matthias Klose wrote: - the 2.7 branch is the only branch which doesn't have expected release dates on the calendar. Which calendar? I see 2.7.4, 3.2.4 (its final release), and 3.3.1 on the Release Schecule at python.org. And from a distributor/vendor point of view, I think yearly releases are too seldom. Such a release could end up only up to 24 months later in a (linux) distribution. Some subset of 'we' proposed 5 instead of 2 years of bugfix support for 2.7, released 2010 July 4, but no particular interval, especially after the first 2 years. - there were way too may regressions checked in on at least the 2.7 branch. Regressions? That normally means adding a bug as part of a patch, especially one that was previously fixed. We continually add tests to try to prevent that. What period of time do you mean 'were' to refer to? > Is it just our vcs merge model that we first have to check in on the branches, and then merge to the trunk? Mercurial works best if merges are done in the forward direction. However, this is not relevant to 2.7 patches as they are pushed to tip but *not* merged. The repository is a two-headed monster ;=). > Afaics python is the only project to have such an approach. Others have trunk first, maybe with immediate backport, maybe with later backport. If a patch is first commited to tip (for 3.4) and then backported to 3.3, then when the backport is pushed, a null merge is needed to avoid making a third head, and the dag looks messier. (I believe 'null merge' is the right term, but I have never done this.) My impression is that most 3.x bugfix patches merge forward with little or no change. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
