FAQ

On Thu, Aug 19, 2010 at 1:00 AM, Aristedes Maniatis 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.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 17 of 20 | next ›
Discussion Overview
groupdev @
categoriescayenne
postedAug 18, '10 at 7:34a
activeAug 28, '10 at 2:56p
posts20
users7
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase