On Sep 27, 2007, at 7:18 AM, Philipp von Weitershausen wrote:

On 27 Sep 2007, at 13:07 , Martijn Faassen wrote:
On 9/27/07, Tres Seaver <[EMAIL PROTECTED]> wrote:
Further, anybody who finds the effort of creating a "fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the "release manager" pool.

I'm *not* kidding about that:  taking shortcuts durng the release
process transfers pain / cost to everyone downstream.

While I fully agree that releases should be done with care and
attention, and that doing bad releases creates pain/cost for
everybody, this line of argumentation can be used to back up any form
of complication to the release process. :)

Let's focus on the reasons for each step and keep the discussion at
that level, please? I think it's useful if people ask "is that really
necessary?" for steps in the release process. Just weigh the pros and
cons. I'd like to understand more about the trouble Philipp ran into
doing releases from the original checkout and then tagging.

I've summarized this in another thread [1], but I'll be happy to elaborate here:

* People actually forget to make the tag. This happened to Roger the other day. It happened to Jim before with zc.buildout. I'm not mentioning their names to point fingers. I'm just pointing out that people who've been with us for a long time forget. If the process said they should actually check out the tag, they'll hardly forget.

Having a script we have to mindlessly follow will help.

* People create the wrong tags or tags in the wrong places. This happened to Jim the other day with ZODB 3.7.1. Again, I'm not blaming him. But I believe if he had to check out the tag to make the release, he would've caught his mistake.

I doubt it. I would have probably just rereleased 3.7.1, possibly with 3.7.2 uselessly included.

* People forget to clean up the 'build' directory. This happened to me the other day. Let me elaborate: I have a trunk checkout of zopeproject that I use to develop it. Whenever I wanted to make a release, I'd just prepare it, tag it and generate the distributino from the trunk checkout. The problem was that I had moved stuff around, but the old stuff was still making it to the egg because it still sat around in the 'build' direcdtory that distutils leaves. I know it sucks that distutils doesn't clean up after itself, but that's just the way it is. If you're forced to use a clean checkout, this can't happen.

The build directory is really annoying.

* People forget to check in important files. This happened to Baiju the other day. He created a CHANGES.txt file and referred to it from setup.py. The only problem is that he forgot to check it in. It can happen, I'm not blaming him. The problem is that setuptools looks at which files are in svn in order to create the archive manifest. So CHANGES.txt wasn't in the tarball and the egg was completely uninstallable (because setup.py couldn't be executed since CHANGES.txt was missing).

These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot.

I'm beginning to see a consensus that we should make it impossible to create distributions from the trunk or a release branch.

Yup. BTW, I find it helpful to test source releases by unpacking them and seeing if I can build eggs from the unpacked source. Of course, it would be even better to run the tests. I suspect that a buildout feature could automate this. Something along the lines of a buildout command that: creates distros from the listed develop directories and then installs those distros rather than the develop eggs so that tests could be run against the distros. This would probably be something good to do when I have some time to get back to buildout.


Jim Fulton
Zope Corporation

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to