www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <bri...@infinity.nu>
Subject Re: Clarification on the release requirements
Date Thu, 30 Apr 2009 13:47:15 GMT

Jochen Wiedmann wrote:
> On Thu, Apr 30, 2009 at 9:33 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
>>> But perhaps that's just splitting hairs :)
>> Not at all.
> I think it demonstrates that we shouldn't require a particular
> procedure, because the applicability of such procedures depends on a
> multitude of factors. Instead, we should assume *reasonable*
> principles like reproducability. (Discussing whether tags can be moved
> is, IMO, not reasonable, in particular, because it can be traced in
> SVN.)
> For example, if we can take the SVN tag as a source, then that's
> sufficiently reproducable for me. I can live (and I'd assume that
> everyone else can) with the requirement to export this tag to an
> archive, both for users convenience and to express the fact that a
> "release" has been performed. (Note, that there are usually more SVN
> tags than releases!)
> OTOH, source jar files are definitely insufficient: For example, you
> can't build the thing without a POM file or Ant script, it lacks
> inputs for generating sources, and so on.
> If we could agree to that, then we could leave the technical details
> (for example, cut archive first, then create the tag, or vice versa)
> to the proponents of the respective build systems, SCM systems, and so
> on - and that's where it belongs to, IMO.
Well said, +1. The results are the important thing and it's on the 
shoulders of the PMC to meet some basic requirements during voting. If 
the source archive is totally junk, it should be uncovered at that time. 
How it gets produced is very dependent on things that change from 
project to project, lets agree on some simple principals and make sure 
all releases meet them. I'll take a stab:

1) each release must at a minimum: a) have a tag in the associated scm 
system for traceability reasons and b) produce a signed tarball that is 
sufficient to build or otherwise produce the product by the users. This 
would typically take the form of an archive of the source tree 
comprising the release and generally match the contents of the tag.

2) binaries are provided as a convenience to the users. If they are 
provided, the version given to them must match exactly to the version of 
the source used to produce the binary. (the existing text on the site is 
sufficient for this part imo)

3) all artifacts (source and binary) must be cryptographically signed. 
Voting occurs on the set of produced, signed artifacts. The validation 
that these artifacts meet the above requirements is performed by the PMC 
during the voting process.

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message