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

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

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 17 Apr 2008 15:48:31 -0400

On Thu, Apr 17, 2008 at 3:35 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> [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
> 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!

Just to be clear, for myself as well.

* Anyone can already sign our releases, and we include their
signatures with the release. I used to sign the Windows releases when
I was not a committer, as an example.

* So we are really talking about a process change where we will count
these signatures as votes towards the actual release? Do we want to
have any specific policies in place? Such as at least 1 or 2 full
committer signatures on each file?

* I'd assume all partial committers are automatically included in this
and do not need to be listed in SIGNERS.

* Will we accept -1's from people in SIGNERS?

Mark Phippard
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:48:43 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.