[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Dropping dependencies in tarballs

From: David Anderson <david.anderson_at_calixo.net>
Date: 2006-04-08 18:16:11 CEST

* Justin Erenkrantz <justin@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
Received on Sat Apr 8 18:16:42 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.