My intention here is to start one canonical thread for discussing our
release procedures. Release discussions have been spread over various
threads, and it's getting hard to follow (or am I the only one having
that problem?).
First, a meta-comment:
One of the themes recently has been a failure on all our parts to
anticipate how controversial some proposals might be. Somehow, we all
thought that the Right Way to do releases would be obvious, and that
disagreements would be unlikely. Then we started disagreeing :-).
So my first request is: let's please take a step back, acknowledge to
ourselves that this is going to be a real discussion and debate, and
agree that the issues must worked out in discussion *before* any
changes are instituted. (Not a jab at Justin, by the way. None of us
realized how much there was to discuss here; he just happened to be
the one to find out, by committing changes and then having them
objected to.)
Okay, on to the real discussion:
Below I'll list what seem to be the main issues right now. Please add
to this list if I've left anything out.
1. Should a release tarball be offered up publicly for signing and
testing, and then blessed? Or should it circulate privately
among the full committers, get tested & signed, and *then*
uploaded somewhere public and announced?
Opinions on both sides have been offered. As far as I know,
things currently stand like this:
Justin Erenkrantz and Sander Striker prefer the release process
to be as open as possible, and are willing to live with the risk
that a tarball that was made public might have to be withdrawn
later (i.e., the release number tossed).
Ben Reser and Karl Fogel prefer there to be a single canonical
moment when the release becomes official, and that the tarball
be already signed when it becomes available to the public. Even
though this means a part of the release process is not done
publicly, they feel the reduction in confusion (is the release
"blessed" yet or not?) is worth it.
I suspect more discussion needs to be had about this. My only
intention above is to summarize the current state of things.
2. When should the release tag be made?
This is related to Question (1). It may be more sensible to
resolve Question (1) first, and then address (2), as the answer
to (2) might be more obvious depending on how (1) is resolved.
3. Should dist.sh offer the ability to 'svn export' dependency
trees, or should it insist on using tarballs? More generally,
should dist.sh support release-generation needs other than those
of the Subversion project?
Justin feels a broader dist.sh mission is okay; Karl wants it to
stay narrowly tailored to the Subversion project's needs. I
*think* Ben Reser agrees with Karl, but don't want to put words
in his mouth. Not sure what anyone else thinks.
4. (very minor question) Should the '-apri' and '-apru' options to
dist.sh be changed to '-apu'/'-api' or '-apr-util'/'-apr-iconv'?
The shorter options are consistent with some similar context in
APR and APR-UTIL themselves (I don't remember exactly what).
Justin prefers either the shortest or the longest forms. Ben
Reser and Karl like the status quo.
This is such a bikeshed I'm not even going to go into the pros
and cons here :-). If anyone feels strongly enough that the
status quo should be changed, please just follow up and we'll
discuss. However, I think it would be better to concentrate on
questions (1), (2), and (3). I acknowledge that this amounts to
a de facto decision in favor of the status quo, but again, is it
really worth more discussion? (Hint: please say no.)
Okay. I've tried to gather the main issues here in one thread.
Again, if I left anything out, sorry, just follow up and list it.
I expect that this discussion will be going on during the 1.2 soak
period. For the first 1.2-rc release, may I suggest that we go with
the open version of the testing & signing process, the one preferred
by Justin and Sander?
The reason I say that is *not* because I think that that should be our
regular release process, but merely because it's appropriate for an
initial RC release. After all, re-rolling an RC tarball is no big
deal, and people can clearly see it's an RC anyway -- there is no more
danger of people basing their own stable releases on it than there
would be of them doing so after the signing and testing process is
complete, since the "rc" is in the tarball's name at all times.
As for *who* does the 1.2 release process, I'd like to propose that
Ben Reser handle it, if he's willing. It would be insanity to try to
coordinate multiple RMs for 1.2, when we're in the middle of a big
discussion about our release procedures. For that reason, I'd also
like to propose that we
CUT BEN SOME FREAKIN' SLACK
during the 1.2 process :-). It's quite likely that, for the sake of
getting a candidate out the door, he may have to make some judgement
calls that (later) end up contradicting conclusions our discussions
come to. Please just let it slide, if it happens. It's very hard to
do something complex like a release with everyone looking over your
shoulder, and while participating in a debate about the best way to do
releases.
Our goal here should be to consense on a process for releases for the
next N years, not to make Release Manager's life hell for the release
we happen to be working on right now.
That's all I had to say. Let the games begin!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 4 23:00:03 2005