incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Blue <b...@cloudera.com>
Subject Re: Votes for git repos - commit id vs tag
Date Tue, 23 Dec 2014 02:14:31 GMT
On 12/20/2014 04:07 AM, Bertrand Delacretaz wrote:
> On Sat, Dec 20, 2014 at 7:16 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
>> ...Releases are the tarball(s) prepared by the release manager, not a pointer
>> into the source control system....
>
> Agreed. I also agree with Brane about the pointer into source code
> control system being useful for PMC members to check that the released
> code is what they expect, but as you say long-term it's only the
> signed release tarball that matters.
>
>> ...So, to make this clear to the community, I would discourage to publish the
>> commit ID in the vote request, and only provide the URL link to the
>> tarball(s)....
>
> The way we work in Sling is that the tarball's name points to a
> well-known svn tag URL. This matches your idea of having the commit ID
> or equivalent somewhere else, but easily accessible. I like that.
>
> OTOH I also like to include the tarball archive's digest (sha1 or
> equivalent) in the archived vote thread as that's a long term (*)
> guarantee that what you got is what was voted on.
>
> -Bertrand
>
> (*) As long as the digest algorithm is not broken, that is.

There seems to be some support for release tarballs independent of 
version control and some support for tarballs that are tied back to a 
specific version of the repository (whether SVN tag or git ID).

I think it is not just great for convenience, but necessary to link back 
to version control. That makes it easy for PMC members to verify certain 
aspects of the release that are otherwise difficult. Tasks like 
verifying source additions were correctly mirrored in NOTICE updates are 
important, and we want that to be as easy as possible. If I'm verifying 
an independent tarball, then I can't browse history as easily.

If it is best practice to link to version control, then we have to have 
a way to verify the version control link matches the release.

I think policy should be that a release tarball is based on the most 
reasonable identifier in version control. For svn, that's a tag and 
revision number. For git, that's a commit id/hash.

Projects should have repeatable processes to get the release tarball 
from the identifier that can be verified against the RM's signature. 
`git archive` works most of the time.

Given that there is confusion on this, I think we should decide whether 
it is required or not and update the docs to be more clear. Does that 
require a vote?

One last point: if the requirement is for git id and verification is 
required, then this allows us to use links to preferred mirrors as well, 
which can be easier to work with. As long as both apache git and the 
mirror are given, of course.

rb


-- 
Ryan Blue
Software Engineer
Cloudera, Inc.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message