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

Release signers (was: Only require 2 signatures for zip file?)

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 17 Apr 2008 15:35:24 -0400

[Folks, there is a concrete proposal at the bottom of this mail, I'm
just top-quoting a lot of context first.]

"Mark Phippard" <markphip_at_gmail.com> writes:
> On Sun, Apr 13, 2008 at 1:17 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> It does seem silly that we pretend these two things are the same
>> function:
>>
>> 1) J. Random tends to make non-damaging code contributions, and works
>> well with people in the community, so we want his changes going
>> directly into future releases without them needing prior review
>> (in other words: J. Random is a full committer).
>>
>> 2) J. Random has built and tested on platform X, and we trust his
>> reports of what he encountered (in other words: J. Random can
>> sign releases).
>>
>> Right now, we pretend that (1) is both necessary and sufficient for
>> (2). It is surely sufficient, but it is *not* necessary.
>>
>> But is there any qualification we should require for (2), beyond that
>> someone posts plausible-looking test output to the dev@ list? Should we
>> "know" the person somehow?
>
> If we really wanted to do something, I would suggest adding a "release
> signers" section to our COMMITTERS file. We could then nominate
> people we trust that are not already committers, such as Stefan King
> and some of the AnkhSVN developers etc.
>
> This might also be a way to bring in some of the people that build
> stuff off our bindings.
>
> Of course it all presumes that these people want to go through the
> process of testing and signing a release.

Well, it just means that when they do sign, we trust it. Whether they
actually do sign for a given release is up to them -- though I suspect
Stefan (for example) will.

It shouldn't be a new section in COMMITTERS, though, since it really has
nothing to do with committing now. Instead, let's just create a new
file, SIGNERS, with the understanding that any full committer is
automatically a signer, and that any full committer can add someone to
SIGNERS.

I realize that's not a lot of formal process. But I think we don't
really need even private discussions for this (unlike with commit
access), because it's just a question of how much the person has shown
up on the lists, presented test results, and said sensible things. We
can go with informal for now -- meaning any full committer can add
someone to SIGNERS, and should feel free to discuss it publicly before
doing so -- and if we need to add more process, well, then we will. The
file will state some guidelines to help committers decide whom to add.

Any objections, before I initialize this file with those guidelines and
Stefan Kung's name?

The goal here is to avoid dropping volunteer energy on the floor. If
there are reliable people willing to test and sign, we ought to be
taking advantage of that!

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-17 21:35:41 CEST

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.