Am 03.02.2013 22:20, schrieb Gregory P. Smith: > On Thu, Jan 31, 2013 at 11:14 PM, Antoine Pitrou <solip...@pitrou.net>wrote: > >> On Fri, 1 Feb 2013 11:00:24 +1000 >> Nick Coghlan <ncogh...@gmail.com> wrote: >>> On Fri, Feb 1, 2013 at 9:50 AM, Antoine Pitrou <solip...@pitrou.net> >> wrote: >>>> On Thu, 31 Jan 2013 23:52:27 +0100 (CET) >>>> matthias.klose <python-check...@python.org> 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
