You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Sweet <mi...@easysw.com> on 2006/04/07 20:35:37 UTC
Re: Dropping dependencies in tarballs
Peter N. Lundblad wrote:
> Justin Erenkrantz writes:
> > On 4/7/06, Eric Gillespie <ep...@pretzelnet.org> wrote:
> > > ra-serf seems to me like an excellent opportunity to stop
> > > bundling our dependencies. -0 to adding apr-serf to the
> > > subversion distfile, for 1.4 or any other release.
> >
> > For 1.4, I would really like us to implement the 'base' (no deps) and
> > 'full' (incl. deps) release variants. We talked about doing this for
> > 1.3, but it got dropped. -- justin
> >
>
> The reason it was dropped was that it effectively double the burden on
> tarball verifying, because you had to test it with and without dependencies.
>
> I'd rather like us to drop the shipping of dependencies. People will
> have to fetch some extra packages to build from source. What's the
> big problem with that?
It is not always easy to find the right versions of packages to go
along with Subversion and everything else on your system... It also
means extra config steps to tell Subversion where to find all of the
dependent libraries - /usr/local is not generally in the standard
include or library paths, and that is the default prefix for all of
the dependent libraries that Subversion uses...
I know, cry me a river...
FWIW, I don't care anymore - I now have to jump through those hoops
for OpenSSL, which is *so* braindead on systems without /dev/random
or /dev/urandom. One of these days I'll provide a patch for ra_serf
to support GNU TLS and we can be done with it...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/8/06, David Anderson <da...@calixo.net> wrote:
> What are people thoughts on this besides Justing and me?
"Three sigs per tarball" is what we've done for years. I don't
understand how Justin can say that this was "never Ben Reser's
intention", when Ben Reser *always* held up releases because we were
waiting for 1 more .zip sig, for example. The fact that this policy
is documented in hacking.html is not an accident, or the result of
some giant perpetual misunderstanding: it's what we've all agreed on
and have been deliberately following for a long time now.
I'm not saying there's anything wrong with debating the policy and
changing it; I'm just saying that Justin's objection of "overkill"
is the first and only objection we've ever heard to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by David Anderson <da...@calixo.net>.
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-04-08 08:39:39]:
> That policy was never Ben Reser's or my intention when we started
> asking for multiple sigs on files. Asking for at least six committers
> (3 Unix, 3 Windows) to sign off on a release is overkill that just
> isn't warranted. It's nice-to-have when we have a hyper-active
> committership; but there'll come a day when we need to push out a
> release quickly and we don't have swarms of committers looking over
> the RM's shoulder to get either 6 people to sign off on a release or
> force people to go to heroic steps and test on *both* Win32 and Unix
> in order for their votes to count.
That last part was never my intention (forcing people to test both
win32 and unix to make their sig count).
3 sigs per file is the current policy as per hacking.html, and as I
said, I have never heard anyone suggest otherwise before this, which
is why I'm surprised at what you are saying.
If we are to reduce the requirements from 3 per file to 3 total, my
view is that we are reducing tarball blessing to mindless
rubber-stamping, like granting a seal of approval because it is
something annoying users want, and not because it is supposed to help
overall quality.
What are people thoughts on this besides Justing and me? Perhaps we
should wait for the weekend to out, so that other people can voice
their opinion on this issue, as it seems we're both in quite
fundamental disagreement over what tarball signing is supposed to
convey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/8/06, David Anderson <da...@calixo.net> wrote:
> For as long as I've been the release manager, I've never seen anyone
> advocate anything other than 3 signatures per file (with the provision
> that .tar.gz and .tar.bz2 can be both signed after testing one and
> comparing contents).
That policy was never Ben Reser's or my intention when we started
asking for multiple sigs on files. Asking for at least six committers
(3 Unix, 3 Windows) to sign off on a release is overkill that just
isn't warranted. It's nice-to-have when we have a hyper-active
committership; but there'll come a day when we need to push out a
release quickly and we don't have swarms of committers looking over
the RM's shoulder to get either 6 people to sign off on a release or
force people to go to heroic steps and test on *both* Win32 and Unix
in order for their votes to count. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by David Anderson <da...@calixo.net>.
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-04-07 20:42:48]:
> I've seen you raise this point before, but I believe this is a
> misunderstanding of our intended release processes. I don't believe
> we should need three sigs on *each* file to release that file - we
> should need at least three sigs *in total* to release.
For as long as I've been the release manager, I've never seen anyone
advocate anything other than 3 signatures per file (with the provision
that .tar.gz and .tar.bz2 can be both signed after testing one and
comparing contents).
I believe that only 3 sigs per release is too low to hope to catch any
problems during the blessing phase. Sure, it would make the release
process faster, but having 2 unix sigs and one win32 sig does not
convince me that the packages are ready for release. What if the
win32 signer doesn't notice a problem because he doesn't do a full
6-way test (such is not required by our current policies, a single RA
method and a single backend is sufficient), which makes us release a
win32 package that has a severe bug elsewhere, in an untested region
of the code?
Furthermore, the RM's signature is not, in itself, blessing. It is
originally there so that other committers can verify that they are
testing tarball that wasn't tampered with since the RM uploaded
it. If it were any other way, I could not provide a signature for the
.zip, because I have no working win32 environment to run the tests
in. Granted, I associate my RM signature with a test run of the unix
tarball, but the primary intent of the RM sig is not to bless the
release, but to bless the release to bless, as it were.
> (The assumption is that the RM has signed all of the files as he
> created them.) Having as many sigs as possible is goodness, but we
> shouldn't need every file signed 3 times to issue a release. That's
> way overkill. -- justin
I find 3 to be most acceptable, and that the signature process is
quite speedy when there is a single flavor of Subversion to sign.
In short, I don't believe that compensating a larger number of
packages by lowering our standards is an acceptable option.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/7/06, David Anderson <da...@calixo.net> wrote:
> In reply to the rest of the thread, dependancies were indeed removed,
> in a dual package offering (with deps and without), for 1.3.0-rc1 and
> rc2. The observed effect, as was discussed at the time, was that
> those two tarballs didn't gather 6 signatures within about a working
> week. We reverted to the previous offering for rc3 and later, and
> those gathered sigs in a more timely fashion.
I've seen you raise this point before, but I believe this is a
misunderstanding of our intended release processes. I don't believe
we should need three sigs on *each* file to release that file - we
should need at least three sigs *in total* to release. (The
assumption is that the RM has signed all of the files as he created
them.) Having as many sigs as possible is goodness, but we shouldn't
need every file signed 3 times to issue a release. That's way
overkill. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Michael Sinz <Mi...@sinz.org>.
David Anderson wrote:
> * Nicol?s Lichtmaier <ni...@reloco.com.ar> [2006-04-07 18:09:30]:
>> Why not, instead of "base" and "full", doing this:
>>
>> subversion-1.4.0.tar.gz - Just Subversion
>> subversion-1.4.0-deps.tar.gz - Subversion dependencies.
>
> A very potent idea indeed, thanks for suggesting it!
Yes...
[...]
> And finally, as a tangential aside, it would make distributing an APR
> 1.x ready package much easier, if we want to: just provide two
> dependency bundles, one with APR 0.9 for backward compatibility, and
> one with APR 1.x for those who want a full APR 1.x ready dependency
> suite. And as far as blessing goes, there is still only one
> subversion source package to test, the basic one with no bundled deps.
The only question I have here is how does one say a Subversion tarball is
blessed unless there was some set of versions of dependencies use as part
of the blessing. Without including those you could have developers that
have some mix that is "unnatural" on their systems and thus the code
could end up depending on those features.
Yes, this is true for other libraries (glibc, zlib, etc) but they have
been much more stable in API (they are also much older)
I worry about the fact that APR and NEON tend to have major incompatibilities
between versions, even minor version changes (especially in NEON)
Thus, a split archive (deps and the core source) may make some downloading
smaller (since a fresh rolling of the Subversion code would normally not
change the deps versions) but the testing would still need to be done with
the deps in order to bless a specific combination. Without that, the
blessing process becomes less useful as the combinations needed to reproduce
the various developers blessed version gets unmanageable.
> Thoughts? The dist script can be adapted to perform all of this and
> more, so it's really down to what we feel is right. I'm:
>
> - +1 on shipping a slim tarball and a separate "deps only" tarball
> - +0 on keeping the status quo (and introducing serf for 1.4), and
> - -0 on providing two source code tarballs, with and without deps.
I think that is reasonable, albeit I would be -1 on the two source code
tarballs. The split tarballs works but we need to define the blessing
process relatively strictly such that there is some actual value to the
signatures beyond "some combination works on my machine."
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by David Anderson <da...@calixo.net>.
* Nicol?s Lichtmaier <ni...@reloco.com.ar> [2006-04-07 18:09:30]:
> Why not, instead of "base" and "full", doing this:
>
> subversion-1.4.0.tar.gz - Just Subversion
> subversion-1.4.0-deps.tar.gz - Subversion dependencies.
A very potent idea indeed, thanks for suggesting it!
In reply to the rest of the thread, dependancies were indeed removed,
in a dual package offering (with deps and without), for 1.3.0-rc1 and
rc2. The observed effect, as was discussed at the time, was that
those two tarballs didn't gather 6 signatures within about a working
week. We reverted to the previous offering for rc3 and later, and
those gathered sigs in a more timely fashion.
The fact that the tarballs had rolling problems that were detected
after about 5 days may have skewed this result, but I believe that
everyone who'd been around for previous minor releases noticed a
distinct slowing down of the blessing process at the time, before the
packages were recalled.
If we can get quick signing on 6 packages instead of 3, I'm happy to
oblige and produce tarballs with and without dependencies. However, I
am very much more +1 to nick's proposal of shipping a dep-free
tarball, which can be signed by the usual testing procedure, and a
separate "dependencies only" package, which can be verified by basic
diffing, if required.
I feel that this shifts the emphasis to the "light" tarball as being
our official code release, much more so than providing two flavors of
the Subversion source code.
I think this bundling also settles both sides of the "But I want ease
of source build!" vs. "I don't want to download useless bundled code
I'm not using!" quite elegantly.
And finally, as a tangential aside, it would make distributing an APR
1.x ready package much easier, if we want to: just provide two
dependency bundles, one with APR 0.9 for backward compatibility, and
one with APR 1.x for those who want a full APR 1.x ready dependency
suite. And as far as blessing goes, there is still only one
subversion source package to test, the basic one with no bundled deps.
Thoughts? The dist script can be adapted to perform all of this and
more, so it's really down to what we feel is right. I'm:
- +1 on shipping a slim tarball and a separate "deps only" tarball
- +0 on keeping the status quo (and introducing serf for 1.4), and
- -0 on providing two source code tarballs, with and without deps.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
> It is not always easy to find the right versions of packages to go
> along with Subversion and everything else on your system... It also
> means extra config steps to tell Subversion where to find all of the
> dependent libraries - /usr/local is not generally in the standard
> include or library paths, and that is the default prefix for all of
> the dependent libraries that Subversion uses...
Why not, instead of "base" and "full", doing this:
subversion-1.4.0.tar.gz - Just Subversion
subversion-1.4.0-deps.tar.gz - Subversion dependencies.
The second package wouldn't have subversion itself. It would have all
the dependencies in the expected subdirectories so that by doing:
tar xvzf subversion-1.4.0.tar.gz ; tar xvzf subversion-1.4.0-deps.tar.gz
..you get whay we have today.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org