You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/04/04 20:33:36 UTC
Release procedures improvements.
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
Re: Release procedures improvements.
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> 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?
Doesn't matter, so long as the unblessed and blessed tarballs are
differently named. I like the subversion-X.Y.Z-PRERELEASE.tar.gz idea
proposed later in this thread, FWIW.
> 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.
After the release tarball has been blessed.
> 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?
We consider released, blessed tarballs to be our canonical definition
of "a Subversion release", and IMO that is probably how most project
would define the same for themselved. So our dependencies should be
pulled in from released, blessed tarballs.
And -0.5 on making dist.sh some kind of (more) general purpose tool.
It exists for the sole purpose of release Subversion.
> 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.
Bikeshed. I'll only add that -api is a not-so-unique abbreviation
that maybe possibly perhaps could confuse someone down the road.
> As for *who* does the 1.2 release process, I'd like to propose that
> Ben Reser handle it, if he's willing.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> --On Tuesday, April 5, 2005 12:50 AM +0100 Philip Martin
> <ph...@codematters.co.uk> wrote:
>
>> Yes. The name need not contain 1.2 or even subversion, it's a very
>> short-term label after all, it doesn't need to be recognisable. The
>> tarball can be renamed when the RM decides to release it, all the
>> signtures should remain valid.
>
> I'm concerned that we would then end up with two files that are identical
> in all but name. And, for some reason, that strikes me as odd. -- justin
Not really odd.
Yes, they contain identical bytes, but one is 'blessed' whilst the other is
not.
Makes sense to me.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Wednesday, April 06, 2005 8:29 PM -0700 Ben Reser <be...@reser.org>
wrote:
> This discussion isn't about a specific release, it's about all of the
> releases we do. And there are always differences with the rcs and the
> final release our version reporting has to be different, CHANGES gets
> modified, and so on. So you can't just recycle a tarball.
So if I understand correctly, there are "release candidates" (things
awaiting signing) for "release candidates" (things that are blessed), as
well as a release candidate (of the first type) for the "release" (the
thing with no "rc" on the end).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Ben Reser <be...@reser.org>.
On Wed, Apr 06, 2005 at 03:51:02PM -0700, Kenneth Porter wrote:
> For an RC, I don't think this is as bad as it might sound. Burning through
> RC's is normal. The final release should be identical to the last RC, so
> once you bless it with the required signatures, you copy the tag and rename
> the tarball.
This discussion isn't about a specific release, it's about all of the
releases we do. And there are always differences with the rcs and the
final release our version reporting has to be different, CHANGES gets
modified, and so on. So you can't just recycle a tarball.
--
Ben Reser <be...@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
Re: Release procedures improvements.
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Wednesday, April 06, 2005 12:40 PM -0700 Ben Reser <be...@reser.org>
wrote:
> Given that there is some preference to doing the public route I guess we
> have to be prepared to toss version numbers.
For an RC, I don't think this is as bad as it might sound. Burning through
RC's is normal. The final release should be identical to the last RC, so
once you bless it with the required signatures, you copy the tag and rename
the tarball.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Ben Reser <be...@reser.org>.
On Wed, Apr 06, 2005 at 01:05:12AM -0400, Greg Hudson wrote:
> On Tue, 2005-04-05 at 21:38, kfogel@collab.net wrote:
> > but when unpacked, it would still create
> >
> > subversion-1.2.0-rc1/
>
> I don't think that's really a compelling reason to consider the version
> number gone, if the tarball is named something nondescriptive. But if
> other people do, I won't argue about it at length.
I'm not fond of tossing version numbers for the reasons you pointed out
in your previous email. I guess it comes down to this...
If we're going to publically post prerelease tarballs I guess we don't
have much choice in this. Otherwise we'll have people running around
with a version that identifies itself as 1.2.0-rc1 but it's really our
first crack at it. So then we spend lots of time trying to figure out
why they're having this issue that we've already fixed.
If we don't publically post prerelease tarballs then I agree, there's no
reason to toss version numbers. I think the committers can be
reasponsible enough to trash them if we decide not to use them and to
not pass them onto someone that doesn't know what they are.
Given that there is some preference to doing the public route I guess we
have to be prepared to toss version numbers.
--
Ben Reser <be...@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
Re: Release procedures improvements.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-04-05 at 21:38, kfogel@collab.net wrote:
> but when unpacked, it would still create
>
> subversion-1.2.0-rc1/
I don't think that's really a compelling reason to consider the version
number gone, if the tarball is named something nondescriptive. But if
other people do, I won't argue about it at length.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Why not just name the prerelease tarballs something irrelevant, than?
> Version numbers are cheap, but they're not *that* cheap; it's a little
> confusing for 1.1.3 to be succeeded by 1.1.7. If we have a way to avoid
> spending them on prerelease testing (and it seems like it should be
> really, really simple to avoid it), then we should avoid it.
Well, the problem is that, in this proposal, the prerelease unpacks
into a directory named *exactly* what the release will be named. That
is, we may call the prerelease
subversion-20050405-PRERELEASE.tar.gz
but when unpacked, it would still create
subversion-1.2.0-rc1/
According to Justin's proposal, we have to treat that unpackment name
as unique forever. If we find a problem with the prerelease, then we
cannot simply release
subversion-20050411-PRERELEASE.tar.gz
but still have it unpack into
subversion-1.2.0-rc1/
It must unpack into something new, probably
subversion-1.2.0-rc2/
(I'm just using these as examples; I'm not proposing that we change
how we're doing the actual 1.2.0-rc* releases.)
So, I don't see how keeping the version number out of the prerelease
tarball's name saves us anything. We still have to toss the version
number if problem is discovered.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-04-04 at 23:12, kfogel@collab.net wrote:
> But if it *doesn't* pass the test-&-sign stage, then we don't ever
> release
>
> subversion-X.Y.Z.tar.gz
>
> Instead, we start over with
>
> subversion-X.Y.<Z+1>-prerelease.tar.gz
Why not just name the prerelease tarballs something irrelevant, than?
Version numbers are cheap, but they're not *that* cheap; it's a little
confusing for 1.1.3 to be succeeded by 1.1.7. If we have a way to avoid
spending them on prerelease testing (and it seems like it should be
really, really simple to avoid it), then we should avoid it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, April 4, 2005 10:12 PM -0500 kfogel@collab.net wrote:
> I understand your concern now. If we put out
>
> subversion-X.Y.Z-prerelease.tar.gz
>
> and that gets tested and signed and eventually released, then we just
> knock the "-prerelease" off the name and release that exact tarball.
> But if it *doesn't* pass the test-&-sign stage, then we don't ever
> release
>
> subversion-X.Y.Z.tar.gz
>
> Instead, we start over with
>
> subversion-X.Y.<Z+1>-prerelease.tar.gz
>
> So, we'd still avoid the jump-the-gun problem, but we wouldn't avoid
> the toss-the-release-number problem (but that's okay, as that was
> never considered a big problem by anyone anyway).
>
> I think I'm okay with that policy, if I've summarized it correctly.
Yes, the policy that you described matches what I meant, but clearer. =)
If we do this, then I'm happy with the -prerelease name.
> But instead of committing to it like a real mensch, I'll be all
> wishy-washy and tentative and see what others think about it first.
Ha. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> So, in short, once we release -PRERELEASE for signatures, it means
> that we can't turn around and reuse that version number for a 'final'
> release.
>
> Does that make sense? -- justin
I understand your concern now. If we put out
subversion-X.Y.Z-prerelease.tar.gz
and that gets tested and signed and eventually released, then we just
knock the "-prerelease" off the name and release that exact tarball.
But if it *doesn't* pass the test-&-sign stage, then we don't ever
release
subversion-X.Y.Z.tar.gz
Instead, we start over with
subversion-X.Y.<Z+1>-prerelease.tar.gz
So, we'd still avoid the jump-the-gun problem, but we wouldn't avoid
the toss-the-release-number problem (but that's okay, as that was
never considered a big problem by anyone anyway).
I think I'm okay with that policy, if I've summarized it correctly.
But instead of committing to it like a real mensch, I'll be all
wishy-washy and tentative and see what others think about it first.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, April 4, 2005 6:37 PM -0500 kfogel@collab.net wrote:
> But can we can come up with a concrete reason why that would bother
> us? It seems odd to me too, at first, but I can't really say that it
> causes a problem -- and it certainly *solves* some problems...
If we say that if we release for signatures:
subversion-1.5.9-PRERELEASE.tar.gz (using your example)
and that we yank it for whatever reason, that it means that we can not release:
subversion-1.5.9.tar.gz
then I'd be fine with this, I guess.
What I'm opposed to (and unclear whether this is what is being suggested) is
that we have subversion-1.5.9-PRERELEASE.tar.gz that says it is "Subversion
1.5.9" and extracts as such and there is a *different* subversion-1.5.9.tar.gz
that we eventually released.
So, in short, once we release -PRERELEASE for signatures, it means that we
can't turn around and reuse that version number for a 'final' release.
Does that make sense? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> > Yes. The name need not contain 1.2 or even subversion, it's a very
> > short-term label after all, it doesn't need to be recognisable. The
> > tarball can be renamed when the RM decides to release it, all the
> > signtures should remain valid.
>
> I'm concerned that we would then end up with two files that are
> identical in all but name. And, for some reason, that strikes me as
> odd. -- justin
But can we can come up with a concrete reason why that would bother
us? It seems odd to me too, at first, but I can't really say that it
causes a problem -- and it certainly *solves* some problems...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Tuesday, April 5, 2005 12:50 AM +0100 Philip Martin
> <ph...@codematters.co.uk> wrote:
>
>> Yes. The name need not contain 1.2 or even subversion, it's a very
>> short-term label after all, it doesn't need to be recognisable. The
>> tarball can be renamed when the RM decides to release it, all the
>> signtures should remain valid.
>
>
> I'm concerned that we would then end up with two files that are
> identical in all but name. And, for some reason, that strikes me as
> odd. -- justin
Now this I really don't understand. A file name is not a holy relic.
This is *exactly* like making a tag in the repostory -- for a moment,
you have two trees that are identical in all but URL. Big deal.
Using a different name for the prerelease tarball *and the prerelease
tag* will solve 99% of the jump-the-gun problems, and will still let us
keep the testing/signing public. So:
1.1.x-prerelease.(tar.(gz|bz2)|zip)
and
tags/1.1.x-prerelease
Then "blessing" includes renaming the tag and the tarballs. Signatures,
checksums etc remain valid, you can cut the tarball from the tag (which
is imho a better than modifying svn_version.h in the tag to fit the
tarball).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-04-04 at 20:58, Justin Erenkrantz wrote:
> I'm concerned that we would then end up with two files that are identical
> in all but name. And, for some reason, that strikes me as odd. -- justin
I say we name them after historical subversives (e.g. guy-fawkes.tar.gz)
and take them down as soon as the blessed tarball is released. I don't
see how that could be considered odd.
(The candidates don't even show up in the Subversion file area, do
they? As far as I know, they generally go up at some random location on
the web under the control of the RM.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, April 5, 2005 12:50 AM +0100 Philip Martin
<ph...@codematters.co.uk> wrote:
> Yes. The name need not contain 1.2 or even subversion, it's a very
> short-term label after all, it doesn't need to be recognisable. The
> tarball can be renamed when the RM decides to release it, all the
> signtures should remain valid.
I'm concerned that we would then end up with two files that are identical
in all but name. And, for some reason, that strikes me as odd. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Ben Reser <be...@reser.org>.
On Mon, Apr 04, 2005 at 06:32:49PM -0500, kfogel@collab.net wrote:
> I like this solution. It allows us to do everything openly, yet
> greatly reduces the risk of people treating the thing like a release
> prematurely.
>
> Ben, Justin, et al, thoughts?
I'm okay with it. I don't think it's likely someone is going to "lose"
the PRERELEASE naming on the file. Only downsides I can think of is
it's going to alter the output of (md5|sha1)sum commands a little. But
I don't think that's a reason not to do it.
That said I'm still not thrilled with it. Just not seeing any important
reasons it's bad.
--
Ben Reser <be...@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
Re: Release procedures improvements.
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> > Philip, are you proposing that we give test tarballs a name like
> >
> > subversion-1.2.0-PRERELEASE.tar.gz
> >
> > or something like that, but which would unpack into subversion-1.2.0/
> > and in every other respect look like the final tarball?
> >
> > No sarcasm intended, btw. I think this might be a great solution to
> > the problem of doing things transparently while not prematurely
> > releasing. I just want to make sure I understand the proposal.
>
> Yes. The name need not contain 1.2 or even subversion, it's a very
> short-term label after all, it doesn't need to be recognisable. The
> tarball can be renamed when the RM decides to release it, all the
> signtures should remain valid.
I like this solution. It allows us to do everything openly, yet
greatly reduces the risk of people treating the thing like a release
prematurely.
Ben, Justin, et al, thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>> > 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.
>>
>> Why does the test tarball need such a name?
>
> Philip, are you proposing that we give test tarballs a name like
>
> subversion-1.2.0-PRERELEASE.tar.gz
>
> or something like that, but which would unpack into subversion-1.2.0/
> and in every other respect look like the final tarball?
>
> No sarcasm intended, btw. I think this might be a great solution to
> the problem of doing things transparently while not prematurely
> releasing. I just want to make sure I understand the proposal.
Yes. The name need not contain 1.2 or even subversion, it's a very
short-term label after all, it doesn't need to be recognisable. The
tarball can be renamed when the RM decides to release it, all the
signtures should remain valid.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> > 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.
>
> Why does the test tarball need such a name?
Philip, are you proposing that we give test tarballs a name like
subversion-1.2.0-PRERELEASE.tar.gz
or something like that, but which would unpack into subversion-1.2.0/
and in every other respect look like the final tarball?
No sarcasm intended, btw. I think this might be a great solution to
the problem of doing things transparently while not prematurely
releasing. I just want to make sure I understand the proposal.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Reser <be...@reser.org> writes:
> 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.
Why does the test tarball need such a name?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release procedures improvements.
Posted by Ben Reser <be...@reser.org>.
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 <be...@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