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
