Return-Path: Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: (qmail 34592 invoked from network); 30 Apr 2009 13:47:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Apr 2009 13:47:52 -0000 Received: (qmail 88893 invoked by uid 500); 30 Apr 2009 13:47:52 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 88612 invoked by uid 500); 30 Apr 2009 13:47:51 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 88604 invoked by uid 99); 30 Apr 2009 13:47:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Apr 2009 13:47:51 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 74.125.44.30 is neither permitted nor denied by domain of brianf@infinity.nu) Received: from [74.125.44.30] (HELO yx-out-2324.google.com) (74.125.44.30) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Apr 2009 13:47:41 +0000 Received: by yx-out-2324.google.com with SMTP id 8so1084541yxb.59 for ; Thu, 30 Apr 2009 06:47:19 -0700 (PDT) Received: by 10.90.79.17 with SMTP id c17mr205740agb.63.1241099238988; Thu, 30 Apr 2009 06:47:18 -0700 (PDT) Received: from ?192.168.101.11? (c-98-229-140-52.hsd1.nh.comcast.net [98.229.140.52]) by mx.google.com with ESMTPS id 2sm3612704agd.34.2009.04.30.06.47.17 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 06:47:18 -0700 (PDT) Message-ID: <49F9ABE3.2050508@infinity.nu> Date: Thu, 30 Apr 2009 09:47:15 -0400 From: Brian Fox User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: legal-discuss@apache.org Subject: Re: Clarification on the release requirements References: <49F71CCF.4030204@infinity.nu> <3b3f27c60904291706r27b9eb42l171809ecae43c33c@mail.gmail.com> <3b3f27c60904291908k6e01dfdet7abf7a20ad8c6f82@mail.gmail.com> <057BE7E1-F459-4CD6-A5A3-21E093A7D405@dslextreme.com> <640823.4954.qm@web54404.mail.yahoo.com> <49F95145.7030805@rowe-clan.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Jochen Wiedmann wrote: > On Thu, Apr 30, 2009 at 9:33 AM, Niclas Hedhman 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