On 28/08/10 2:18 AM, Mike Kienenberger wrote:
> On Thu, Aug 19, 2010 at 1:00 AM, Aristedes Maniatis<ar..aniatis.org> wrote:
>> As a PMC I suggest that our rules should be:
>>
>> 1. Every release must include both the source and binaries built for
>> supported platforms. They can be packaged separately but must be made
>> available from the same download page.
>
> Rule: must include a source package
> Guideline: would be nice to also have binaries
I'm not talking about Apache Foundation rules here, I'm talking about the rules we as a PMC want to create for ourselves. We need to encompass the requirements of the Foundation, but we need to do it in relation to how we operate and what outcomes we want.
In our case, we want to release binaries every time, and I personally will be voting against any release which does not contain binaries. Let me know if you disagree, but I'm putting that down as a 'rule'.
>> 2. Although not an Apache requirement to do so, we will package all
>> essential runtime dependencies within our binary distribution packages, but
>> not within the source package. Optional dependencies will not be included in
>> the distribution.
>
> I see value in providing a package containing essential runtime dependencies.
> However, I don't see it as a requirement. I suspect that due to the
> size of the dependencies and the prevalence of maven, most people
> would prefer that the binary package not contain the dependencies.
> Might be wrong about this, though.
Some of our dependencies are a little obscure, so perhaps it is a good idea to bundle them unless we are confident they are in a repo somewhere reliable. I've seen that Andrus is working on improving this already.
Obviously there is a line to draw. We can never release source which has *everything* you need to build the binaries since we aren't bundling the JDK.
>> b. satisfy themselves that the source matches the appropriate svn tag (I
>> don't know how to do that though: how do I check that Andrus didn't
>> accidentally build the distribution without a clean svn checkout or that his
>> git-svn tool didn't do something wacky?)
>
> No -- why does it matter where the source came from for the purposes
> of a release?
Because you yourself said:
> In practice, I think the primary bulk of the rest of the source
> licensing checks happen during the the commit process as a "best
> effort" rather than "guaranteed perfection".
Personally I'm confident that the code in SVN is appropriately licensed since I read pretty much every commit that goes past. But I've been chastised twice now about my voting methodology. I've previously taken it for granted that the source in SVN is what ends up in the release and therefore until now I've done little independent checking of the packaged source. I've focussed on ensuring the binaries are sane. Mike, as you say, more emphasis should be given to verifying the source, but I'm trying to understand what that means in reality.
>> c. satisfy themselves that the licensing requirements are met (this will
>> usually be achieved by [b] since all committers have a CLA, and ensuring
>> that all notices are in place)
>
> Yes. Rule.
>
>> d. satisfy themselves that the binary distribution is sane and passes basic
>> usability tests. For example, that the Cayenne modeler runs and the main jar
>> passes some basic tests.
>
> Not a rule, but a good idea. Not legally required for a release.
Again, I'm trying to create some rules for ourselves as PMC members against your (correct) statement that new PMC members don't always know what is expected of them. Having a checklist for releases seems like a starting point.
> Again, the goal of our releases is to provide quality software, but
> the only legal requirements of a release are that it meet certain
> legal and procedural criteria, not that it's quality software.
As PMC members we have a responsibility to do both regardless of the Foundation rules.
Regards
Ari
-- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Sat Aug 28 2010 - 06:14:24 UTC