On Mon, Apr 04, 2005 at 03:33:36PM -0500, kfogel@collab.net wrote:
> 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.
Correct that is my feeling. I'll add that the argument here about
avoiding "smokey back room decisions" really doesn't hold up in my
opinion. We're not "hiding" the release process much at all. What
we're hiding is the copy of the tarball until we release it. Anyone
that really wants to see what we're doing can look at the branch. The
branch has never caused any confusion.
All of the decisions about what goes into the release will still happen
on the dev list, STATUS, and somewhat on IRC. So anyone that wants to
follow can. Same is true with scheduling. The only thing that isn't
made available to the public would be the tarball we think we're going
to release. If committers cooperate and make an effort to test we can
have that tarball approved by the following day. Especially, if we
avoid cutting tarballs on Friday and do it during the week when more
people are around and have time to review that sort of thing.
As the BSD guy points out, no matter how many warnings and danger signs
we put up. If we post a tarball that is named like a official release
tarball people are going to use it like that. Once that tarball gets
downloaded all the markings on email, the directory name on the website,
or whatever other warnings we have along with it are gone. We can't
assume that this information is going to stay with it.
> 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.
The same issues with the tarball being public until we've "blessed" it
apply to the tag. As it stands now there is absolutely no way of
looking at a tag and knowing if the code has been blessed as a release
or if it's somtehing we're considering of just brown-bagging and
starting over with a new number.
We could alleviate some of that by making a separate releases tag
directory. But I see at least one problem with this a complete solution
to the problem.
We have zillions of places that refer to:
http://svn.collab.net/repos/svn/tags/x.y.z
We can't get rid of those. People are used to them. If we start making
a tag in tags for the tarball as soon as we cut it and then make another
in a releases directory after we "bless" the release then how are people
going to know that they should be using the tags in the releases
directory and not the tags directory? My guess is they won't. They'll
continue to use the tags directory completely ignorant that they might
be getting a release that we decided to trash as bad.
My solution to that is if we decide we want this tag at tarball creation
is to name the tag 1.1.4-test. The tag can simply be renamed to 1.1.4
when we "bless" the release. It avoids any potential confusion. I
doubt anyone is likely to think 1.1.4-test is a "blessed" release.
Justin, opposes this but I really don't understand why. But for the
same reason that I odn't understand his position is the reason I don't
understand why we even need this tag. The tarball is actually cut from
the release branch at a specific revision. The only difference is the
svn_version.h which is changed by a program in a completely predictable
way.
This difference is completely irrelevent to testing and really anyone
testing to bless a release needs to be testing the tarball not the tag
because the tarball introduces more ways for things to break (libtool,
configure, etc...). But if anyone wants to verify that the tarball
really contains what it should:
a) The svn_version.h in the tarball identifies the revision it was cut
from and CHANGES should identify the branch. If we wanted to we could
even add a comment in svn_version.h that was set by dist.sh that
identified the branch just to make it easier to find this info in one
spot.
b) There's no reason this info can't be posted along with the tarball.
In the past most of the release work has happened on IRC. So I always
explicitly said on IRC what branch and revision I was cutting from so
that people who were helping to test knew. Nobody ever seemed to be
confused by this or found it to be a problem.
So the ultimate questions are:
Who exactly is going to be using that tag between the time we create the
tarball and we bless it?
What is the benefit of this tag when the same information is available
already from the branch?
I think the TSVN 1.1.4 release shows us clearly what the risks of that
tag are.
> 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.
I *think* I agree with you. But I'm not entirely clear on that. So
I'll say in my own words what I think.
I have no problem adding functionality to dist.sh (even if it isn't
something we particularly need in cutting our own official releases):
a) It isn't overly complicated and likely to require a lot of work to
maintain.
b) It doesn't compromise our own release process.
In my opinion the export on dependency trees fails at least the 2nd of
those tests. I'm not sure about the first one, it really depends on the
other projects and how stable their organization of their repos stays.
I think I've been clear on why I think it compromises our release
process in previous emails so I won't reiterate it here.
> 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.)
I'll compromise on this as say we can accept the alternatives as meaning
the same thing as long as we don't use -api as the advertised interface.
Justin can then use -api and -apu if it makes more sense to him and I
can use -apri and -apru since it makes sense to me. Everyone is happy.
> 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 think you left out one thing that isn't really been discussed much.
But it's kinda floating around in at least some peoples minds.
Just what do you sign if you test? What are the standards to decide
you should sign a tarball. Do you need to test the .bz2 and .gz files
separately. I have a few answers to this.
Due to the way the dist.sh script works (and this was done on purpose)
we produce the tar file once and then compress it twice. This means
that the resulting tar files after uncompressing are identical. So this
is how I believe you can sign both .tar.{gz,bz2} files if you've tested
one. You have two choices to do that:
a) If we adopt using the -n option to gzip to make sure that the files
recompress the same you can download one and recompress the resulting
tar with the other and your signature should be valid on the other.
This works nicely for people that don't want to download both but still
want to sign both.
b) You can download both. Uncompress and extract one and test it. Then
simply expand both and get the md5sum of the tarball, if they match then
just sign the other. This is handy if you already have both for
whatever reason and don't want to wait on the recompress.
Signing the .zip file is a different story. The RM has to sign the zip
file to give people a way to verify it came from then. Everyone else
that signs it should have tested it. Given that neither Justin or I
have access to Windows that means we are signing it without testing.
This effectively makes the .zip require 2 testing signatures. I believe
Sussman, Erik and brane are all in a position to do this testing.
As far as what testing should be required to constitute signing off on
it. I think whatever testing is documented in releases.txt. That means
building everything (including most bindings, I realize some platforms
or people may not be in a position to test JavaHL) and run the test
suites (including the perl one). For the non-bindings tests that means
6 passes of makecheck, 1 for each RA layer and again for each FS layer
(2*3 = 6).
Yes this takes some time even on the best of machines. If people are
willing to do more then more power to them. But I think the above
should be the minimum.
> 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.
That's fine with me. I agree the risk for a rc tarball is minimal.
> 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.
That's fine I will be more than happy to handle 1.2. I would add that I
think we should continue following the existing release procedures and
use the dist.sh as it exists without any further changes (though I would
like to revert r11934 since nobody seems to object about my complaints
with it. But I can wait to do that for the time being).
Granted, some minor changes may need to be made due to bugs or whatnot,
but I really don't forsee any right now.
As far as signing. I'm content with holding up blessing a release
already by asking for testing and signing. We can just leave it up to
people to use their best judgement on deciding what they should sign
until we've documented the policies.
> 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.
Agreed.
--
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 Apr 5 00:26:20 2005