On Mon, Feb 21, 2005 at 10:10:15AM -0800, Justin Erenkrantz wrote:
> Based on my reading of notes/releases.txt, there are a number of implicit
> things that must be understood in order to do a release. That document
> isn't enough on its own for anyone to do a release that we'd consider
> 'good'.
>
> It doesn't describe how to create a release from a branch - only from
> trunk. Nor, does it describe our current policy for summarizing CHANGES
> entries as we now want the RM to do it.
Sure it does, it tells you to skip to step 3. As far as CHANGES, I've
only ever written it once. Every other time, sussman has done it. I'm
not sure how'd you document it anyway. It's straightforward and
obvious. But for what it's worth is included in the steps.
> Where does it say what are the 'good' versions of autoconf or libtool?
> Currently, dist.sh or buildcheck.sh don't enforce that - and that's
> badness, IMHO.
For reference:
libtool-1.4.3
autoconf-2.57 (but it's not required to be these version actually, see
below).
The big requirement here is that these not be hacked on versions by the
distributions. They have to be clean copies from the GNU tarballs. 90%
of the problems we've had have been hacks from distributions to "fix"
things for their own distribution but that don't work on other
platforms.
The libtool requirement is the most restrictive one. 1.4.3 works on the
most platforms without the issues we've had with 1.5.x. 1.5.x fixes the
issues we have with other 1.4.x releases, but introduces the need for a
C++ compiler which we didn't want. Supposedly this has been fixed but
we had agreed to leave well enough alone until 1.2 when we were going to
try 1.5.x on the betas.
That said there isn't a good way to check that people have a good
libtool or autoconf from our scripts. Most of the hacks that break
things are silent changes that we can't detect.
The reason I haven't documented this was because my intention was to
make my chroot environment available that I use to do the builds. I
just haven't gotten around to publishing it. Though it's not going to
really help you since you apparently don't have access to linux i586.
Once we remove the libtool issue at 1.2.x then we'll be down to "Don't
use distribution hacked versions" Which isn't something we can automate
around. Documenting what is needed is good and should be done.
> It also doesn't describe how to create the .zip CRLF source files - which
> is something we've been intending to do since 1.1 came out - although
> dist.sh seems to have the required bits to do this, but it isn't
> documented.
A lot of the dist.sh options I use aren't documented in releases.txt but
90% of them aren't actually needed to cut a release. They exist to
streamline my release process. Someone cutting a release for the first
time isn't probably going to find them that useful. But it's true that
I've never put the zip instructions in the releases.txt file, I suppose
I should. Mostly because it's just a matter of rerunning the same
dist.sh command with -zip and with the Windows APR, APR-util and
instead of the Unix versions and adding in APR-iconv.
If anyone is curious this exactly what I used to build 1.1.3:
./dist.sh -v 1.1.3 -r 12730 -pr branches/1.1.x \
-neon ~/in-tree-libraries/neon-0.24.7 \
-apr ~/in-tree-libraries/httpd-2.0.52/srclib/apr \
-apru ~/in-tree-libraries/httpd-2.0.52/srclib/apr-util/
./dist.sh -v 1.1.3 -r 12730 -pr branches/1.1.x \
-neon ~/in-tree-libraries/neon-0.24.7 \
-apr ~/win32-in-tree-libraries/httpd-2.0.52/srclib/apr \
-apru ~/win32-in-tree-libraries/httpd-2.0.52/srclib/apr-util/ \
-apri ~/win32-in-tree-libraries/httpd-2.0.52/srclib/apr-iconv/ -zip
Rather than copying the various libs into the right place with the right
name for dist.sh to just find them I've added options for me just to
tell it where they are. So I can keep reusing the same files over and
over.
I use the .zip packaging of Apache as the source for the APR files
needed for our .zip packaging and the .tar.gz packaging of Apache as the
source for the Unix files. Neon has no separate packaging so I use the
same files for both...
However, if you're only cutting a single release the old way of just
putting the folders in the wc works just fine. Incidentally, the
instructions tell you to use a wc, but you really don't need it anymore,
you could just download dist.sh with svn cat and cut it without a wc.
> These are only some of the things I intend to address. And, by having
> someone go through the release process who hasn't done it before (or
> recently) with an eye on getting these docs right, I think we'll end up
> with a far better document that'll be closer to our ideal.
Well really I don't think you have to cut a release to address these.
If you really want to I don't really care if you do. Nobody has stopped
anyone from taking the time to try and cut a release and then adjusting
or asking that the documentation be adjusted based on that. These
things don't have to be done by the RM. Other people have made some
adjustments to the instructions and dist.sh in the past.
So what are the other things you intend to address? Let's just talk
about them and address them. The things you've mentioned above are
oversights in the releases.txt documentation that I will be more than
happy to fix.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 22 23:31:35 2005