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

[Karl Fogel <kf...@red-bean.com>]

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

"Mark Phippard" <ma...@gmail.com> writes:
> On Sun, Apr 13, 2008 at 1:17 PM, Karl Fogel <kf...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Release signers

[Karl Fogel <kf...@red-bean.com>]

"Mark Phippard" <ma...@gmail.com> writes:
> * 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.

Right.

> * 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 was only talking about the voting significance -- in other words,
proposing that we open up the voting a bit, since testing Subversion has
no necessary connection to writing code.

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

No, I don't assume that.  We give people partial commit access to
maintain Perl scripts and whatnot; nothing about the process says they
reliably test Subversion.

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

Good question.  No, a -1 just means there's a problem -- in which case
the right course is to describe the problem, and let the committers
(whose names are really on the line) decide what to do about it.

Another possibility is to loosen our formal release requirements and
just let the release manager decide how much testing (and by whom) is
enough.  I'd actually be comfortable with that too.  (Not proposing
changing the soak periods, though.)

I dunno.  The more I think about it, the less enthused I am.  The
SIGNERS file is eventually going to be a headache to maintain;
meanwhile, we've already seen more committers step up to do signing.
Let's just see how that goes and revisit if we must.

-Karl, thinking more carefully now


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Mark Phippard <ma...@gmail.com>]

On Thu, Apr 17, 2008 at 3:35 PM, Karl Fogel <kf...@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" <ma...@gmail.com> writes:
>  > On Sun, Apr 13, 2008 at 1:17 PM, Karl Fogel <kf...@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!

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?

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org