jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Concerns about release vote behaviour
Date Mon, 21 Apr 2008 18:20:42 GMT
On Apr 20, 2008, at 6:03 AM, Felix Meschberger wrote:

> I have a growing concern about our latest releases. Most of the  
> time we
> barely get the required minimum of 3 +1 votes to release the stuff.  
> Take
> as an example some recent release vote results:
>
>    * Jackrabbit 1.3.4 - 3 votes
>    * jackrabbit-core 1.4.2 - 4 votes (of which 1 non-binding)
>    * Jackrabbit 1.4 - 4 votes (of which one non-binding -1)
>    * jackrabbit-jcr-commons 1.4.2 - 4 votest
>    * jackrabbit-core 1.4.1 - 4 votes
>    * Jackrabbit 1.3.3 - 5 votes (of which 1 non-binding)
>    * Jackrabbit 1.3.1 - 5 votes (of which 2 non-binding)
>
>
> Now, compared to the number of committers/PMC members we have - 20
> according to [1] - this is IMHO not enough backing for releases.

Three people giving a true +1 to a release is adequate.  Not ideal, but
still adequate, providing that none of those +1s are bogus.

> How come ? Could it be that we just don't feel comfortable enough with
> the code base we are working on day-on and day-off ? Is it, that we
> cannot bear the responsibility of releasing some code, we could not  
> test
> thorougly ourselves ? I cannot tell. And the reasons for these
> abstentions are probably none of my business.

The Apache release process is designed to work with part-time  
volunteers.
We only need enough attention, not absolute attention.

> What I really am looking for is more votes on our releases to show our
> user community that the Jackrabbit PMC is in fact proud and  
> confident of
> its product.
>
> It is true, that the PMC is responsible for the published releases:
>         The main role of the PMC is not code and not coding - but to
>         ensure that all legal issues are addressed, that procedure is
>         followed, and that each and every release is the product of  
> the
>         community as a whole (see [2]).
>
> So a release vote, as I understand it, is not primarily about whether
> the product code is 100% correct. Rather the question is whether the
> code was developped correctly with respect to the community and that
> legal issues have been addressed, e.g. required files such as LICENSE
> and NOTICE files are in place.
>
> And this is actually, what I do when considering my vote:
>
>    * I get the complete release from the release candidate location
>    * I check all checksums and signatures
>    * I run rat to check for the license headers ([3] and [4])
>    * Check NOTICE files
>
> If all goes well, which it normally does, I vote +1. There is nothing
> more I do.

Sorry, that is a bogus +1.  All of your release votes are now invalid.

Each time you do that you decrease the ability of the team as a whole
to verify that at least three people have built the source code on their
own system and run whatever normal tests that they consider  
sufficient to
verify that the SOURCE CODE provided does indeed build into a release
that is, in their opinion, at least as good if not better than the
prior release of that product.  That's what +1 means for a release.

The binaries are irrelevant.  Aside from checking the signatures, just
trust that the RM built them from the same source.  What matters for the
release vote is that the source code matches what we have in subversion,
is buildable, and runs on your own platform.  I stopped voting  
because my
platform stopped working, but I should be able to rely on the others to
verify that it is just my personal install of java that sucks and not
our released code.

I don't care how often a release gets delayed because not enough people
have built and tested it -- they will show up when progress is delayed.
I do care a great deal when folks say that they will submit bogus +1s
just to make up the appearance of progress.  That simply is not good  
enough.
If it persists, you will be removed from the PMC.  Apache cannot afford
to allow releases to become an exercise in marketing.

....Roy


Mime
View raw message