cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: 3.0.1 - next steps
Date Thu, 19 Aug 2010 05:00:12 GMT
On 18/08/10 7:52 PM, Andrus Adamchik wrote:
> It does go contrary to what I said. Specifically<quote>Binary packages MUST be
built from the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.</quote>
 -http://markmail.org/message/3odlybipss4wnczl  ... So maybe instead of arguing against this
further, I should try creating a source package assembly and building it into binary assemblies.
Sure it will be fun :-/

I don't understand how this is practical or useful. I just read that thread on the legal-discuss
list. Apart there being an hour of my life I'll never get back, it is clear that almost no
one actually follows the advice Roy espoused in his email. Here were some interesting emails:

http://markmail.org/thread/uugenepmbvodc4wu
http://markmail.org/thread/di7lflnzsoymyz2v


At any rate, I think it is up to us (the PMC) to decide on some policies and make them clear
in our own documentation. As Mike says, the responsibilities of the PMC members are not crystal
clear to us all. We should put them in writing. Obviously we follow the general Apache policies,
but where they are vague we need to come up with our own interpretations. The general documentation
about PMC responsibilities doesn't even mention releases ( http://www.apache.org/dev/pmc.html
) and the official release documentation ( http://www.apache.org/dev/release-publishing.html
) says only this:

    ...the fundamental requirement for a release is that it consist of the necessary source
code to build the project. Optionally, a release may include compiled binaries for the convenience
of users.


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.

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.

3. All committers are encouraged to vote on releases. Committer votes will be considered by
the PMC (particularly -1 votes will be discussed) when making the final decision, but are
not binding.

4. Each PMC member will do the following before voting on a release:

  a. download the artifacts
  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?)
  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)
  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.
  e. satisfy themselves that the source passes agreed unit tests (either by running them manually
or verifying that Hudson has run those tests against the equivalent source).



In many of the cases above, the difficulty comes down to verifying that the source == svn
checkout. If we assume that might not be the case, then we can't rely on Hudson for running
the right tests, or the svn commit rights for controlling who has submitted the CLA. We would
in theory have to verify that every line of the source was appropriately licensed. I have
no idea how to verify that Andrus' evil twin didn't inject some bit of GPL code into the source
before building it.

Other than my problem around point 4b are the above rules a good summary of the process? Can
we agree on everything else and then see what 4b means to us?


Ari


-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Mime
View raw message