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 , but I'll be happy to
* 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.
Zope3-dev mailing list