On Sat, Aug 28, 2010 at 2:13 AM, Aristedes Maniatis wrote:
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'.
On 28/08/10 2:18 AM, Mike Kienenberger wrote:
On Thu, Aug 19, 2010 at 1:00 AM, Aristedes Maniatis<ari@maniatis.org>
wrote:
Guideline: would be nice to also have binaries
I'm not talking about Apache Foundation rules here, I'm talking about theOn 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 package1. 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.
Guideline: would be nice to also have binaries
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'.
example. At some point, we might have a security issue with Cayenne, and we
might decide that we want to make an immediate release of a single source
file, with no binaries. Most of the time our releases will probably
contain binaries, but if someone decided to make a milestone release of only
source code, I see no reason why we'd disallow it.
2. Although not an Apache requirement to do so, we will package all
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.
I am in favor of doing this. But it needs more discussion. I still thinkessential 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 runtimebut
not within the source package. Optional dependencies will not be included
in
the distribution.
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 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.
rule/requirement is too strong of a word, though. General
practice/guideline if we come to agreement on it.
b. satisfy themselves that the source matches the appropriate svn tag (I
of a release?Because you yourself said:
In practice, I think the primary bulk of the rest of the source
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
d. satisfy themselves that the binary distribution is sane and passes
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.
These sounds fine as an item or items on our checklist. It might even bedon'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 purposesaccidentally build the distribution without a clean svn checkout or that
his
git-svn tool didn't do something wacky?)
of a release?
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 licensedeffort" rather than "guaranteed perfection".
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.that all notices are in place)
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.usability tests. For example, that the Cayenne modeler runs and the main
jar
passes some basic tests.
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.
reasonable as a requirement rather than a guideline.
Again, the goal of our releases is to provide quality software, but
Foundation rules.
I don't want to nitpick, but that's not accurate. As project members wethe 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 thelegal and procedural criteria, not that it's quality software.
Foundation rules.
have a desire to produce quality software. As PMC members we have a
responsibility to meet certain legal and procedural criteria. There are
two different roles (what some people call "hats") involved here. In our
PMC role, our responsibility is to meet the requirements of ASF releases.
But I agree that we also have a strong desire to do more than just release
legally-satisfying packages. But if I consider two people on the extreme
edges -- one who only cares if the software works and one who only cares if
the software meets the legal requirements of the ASF -- the second one is
the only one qualified to be a PMC member.
In summary:
Meeting the legal/procedural requirements of the ASF is a PMC member
requirement. If somone is not willing to do this, they should step down.
There is sometimes room for interpretation on how to determine if we're
meeting the legal requirements (ie, [monitor all commits and verify that the
svn tag matches the source download] VERSUS [run RAT tools] VERSUS [spot
check the code]), but it has to be done. Other times there is no room for
interpretation -- the signatures have to be checked, the source has to be
provided.
And unfortunately, I'm no expert. I've been around a long time and have
seen how many other ASF projects operate, and I read through what
documentation is available, but in the end, I'm not even an Apache member.
I no longer follow infrastructure, legal-discuss, nor the incubator general
mailing list. I did sign up for the new release management mailing list a
couple weeks back. Maybe that's a place we could be asking some of these
questions on topics that are more open for interpretation, but because of
the nature of the ASF, if it's not documented somewhere, it's up for debate,
and often the debate takes several years to work out. The mailing thread
that we've referred to eventually lead to documentation changes, but it
didn't happen right away.
I do have the advantage that I'm a PMC member on the MyFaces project, and
just because of the shear number of subprojects, people involved there, and
the variety of issues there (3rd party add-ons/modules/app-servers with all
kinds of licenses, Java Community Process, NDAs, security issues, maven,
ant, J2EE integration, GSoC), I get to eavesdrop on a lot of
How-It-Works-At-ASF discussions involving people from a bunch of other ASF
projects.
And sometimes when I see something relevant from there pop up, I try to
share over here at Cayenne, where we seem to be a bit more isolated from the
rest of the ASF.
