On 4 March 2014 16:50, Larry Hastings <la...@hastings.org> wrote: > > On 03/03/2014 10:23 PM, Nick Coghlan wrote: > > But at the moment you're making it > *hard* for people to test the release, > > > How? How is testing against a tarball fundamentally different from testing > against an hg-cloned repository? > > I'm really not buying this.
Because there are *zero* instructions in the devguide for tarball based testing. Can it be done? Yes. Is it properly documented such that it is acceptable to rely on it as an essential part of the release process? No. *Never* have we done a feature release where we went dark for most of the release candidate cycle - for past feature releases, the release branch was made at the time of the first rc, and everything merged during that time was subject to two committer review, and everything merged to the release branch was automatically considered as a candidate for including in the next rc/final release. After the switch to Mercurial, the contents of the release branch might not be *exactly* what ended up being released, but they were close enough for all the purposes that anyone cared about. That's not the case here - by instituting the new process where you stopped checking every commit and instead required the creation of specific tracker issues, the default branch of the main repo now has a bunch of stuff listed for 3.4.1 that is a mixture of 3.4.0 and 3.4.1 changes, so it's hard to tell whether or not a particular change is going to make it into 3.4 final. I was prepared to go along with that (since those that do the work get to make the rules), but then you said you were going to go straight from a release candidate that broke two of the most popular Python projects to a final release with the release clone *still* offline for reasons I do not understand. That is *not* OK - if we're skipping rc3 even though rc2 broke both Flask and SQL Alchemy (and possibly Vim), then we need to be able to see *exactly* what is going to be published, including the full history of which commits have been cherry-picked, not just the end result as a tarball. You've given people plenty of warning that you'll be rewriting history in your release clone. That's fine, we can deal, especially for throwaway testing clones - git users handle rewritten history as a matter of course, and it really isn't that scary, even in Mercurial. But the combination of skipping rc3 *and* keeping the release clone offline is not a responsible course of action. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
