cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: 3.0.1 - next steps
Date Fri, 27 Aug 2010 16:18:45 GMT
On Thu, Aug 19, 2010 at 1:00 AM, Aristedes Maniatis <ari@maniatis.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


> 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.

To me, it might make more sense to include them with the source since
they are a required piece to build the source.  Or, as I said earlier,
a separate dependency package.   However, all of this would have to
wait until someone is willing to do the work to make it happen.


> 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.

That's a rule.


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

Yes.

>  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?


>  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.

>  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).

Not a rule, but a good idea.   Not legally required for a release.


> 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.

I don't agree that the source == svn checkout has to match as a
release rule, although it's a good guideline.
However, I don't see it as a really big deal -- I'm pretty sure our
source package is mostly a svn snapshot (correct me if I'm wrong), and
a recursive diff tool could compare the two easily.

This is part of the due dilligence that should be performed for every
commit message.   Sometimes things do sneak in -- we've had it happen
a number of times for MyFaces -- and they have to be dealt with at a
later date.

Running RAT against the source package (not SVN) is one tool that
helps.   Spot checking a few files can help.
I think MyFaces has a code style rule that also verifies copyright
notices in each file.   Running diffs against the current source
versus the last releases source might be another such tool.   While
this is one of the most important responsibilities of the PMC, it's
also one of the most difficult to be comprehensive about.

> 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?

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.

Mime
View raw message