--On Saturday, April 2, 2005 4:55 PM -0800 Ben Reser <ben@reser.org> wrote:
> No it's not. It's a committers thing. Only the committers have the
> power to call something a release. I think the benefits of "community"
> input at that stage is minimal compared to the potential risks to the
> people who don't listen that it's only there for testing.
I have concerns with making release decisions in private (except for where
embargoed security issues are present). We should place trust in the
community, and in return, the community should trust us to produce
high-quality releases. Yet, we gain this trust by making almost every
decision in public.
Note that end-users who want to run bleeding edge code or things straight from
trunk are always able to do so - no matter what we do for a release. The key
audience that we need to inform of these policies are the downstream packagers.
The TortoiseSVN folks jumped the gun on 1.1.4, so we need to make this clearer
in the future so this doesn't repeat itself.
(I'm not entirely opposed to having non-committers also sign a release. I
really haven't thought through the implications in depth, but I'm not seeing a
clear downside of opening up who signs a release other than someone
mis-representing themselves as a Subversion committer. The more keys we add,
the more likely someone will have a direct trust path to someone who signed.)
> Well the sigs will obviously be publically published. I'm not sure how
> much additional information you really expect to people to gain from the
> email with the signature on it.
Such a message may include what platforms they tested on, or if they saw any
caveats with the release. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 03:22:11 2005