incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Wed, 28 Mar 2012 12:39:22 GMT

Of course you, personally, can't be expected to supervise all projects
or fix all documentation. At the same time, there's something a little
depressing about the situation. On the one hand, the principle at work
here is, to paraphrase you, absolutely central to the defined mission
of the Foundation. On the other hand, over all these years, the
Foundation has apparently failed to do two things: to find a way to
document this so clearly that no member, let alone PMC chair let alone
committer could miss it; and to supervise projects sufficiently to
detect divergence. The board can read reports all year long and never
discover that someone has drifted off the rails here.

None of this, however, is what I really want to write about. Consider
me in the role of a PMC member voting on a release with external
dependencies, not included (of course) in the bundle. What do I do?
Well, I fetch the dependency. In source? In binary? From where? And
how do I ensure that I get exactly the same thing that the next voter
over gets? If the build automatically downloads, I don't appear to
have this problem, but, really, what do I know about what that
download is downloading? This all boils down to the semantics of the
vote. All I can really do is attest that the sources are legitimate
Apache sources, and that I was able to build and run something using
*some version of some dependencies*. Is this really good enough? In
our role as serving the public good, is this giving the user community
enough information?

Consider the following thought experiment: what if projects bundled up
their binary dependencies into an archive with a manifest file that
described their provenance, signed them, and put them someplace?
Someplace not 'inside a release'. Then, the source release would be
aligned with a particular, reproducible, version of its dependencies.

If this is still completely unacceptable, the logic seems to lead
inexorable to dealing in Other People's Sources: capturing a snapshot
of their sources so as to be able to state, unequivocally, what the
dependencies are.

Maybe all this reads as pointless quibbling and no one cares about it.
I have another issues to raise, however: the gap between public
perception of Apache releases and legal reality.

When AOO releases, soon, a giant flood of *binary packages* will move
out onto the mirrors. Accompanied, yes, by a source release. Formally,
legally, the only real release is the source package. Realistically,
no end users will touch it. From their point of view, the thing with
the Apache seal of approval that they will trust, download, and
install will be a binary. AOO isn't unique, but it's the starkest
example, because of it's end-user focus. I feel a little bit
disingenuous, in our role as a public charity, about the disparity
between the public perception that we're releasing binary packages and
the facts.

This strikes me, in unhelpful retrospect, as an issue that the board
or membership should have taken up as part of accepting AOO. I don't
have a proposed solution; please don't mistake me for proposing to
tamper with the fundamental 'releases are source' principle. But I
think that something here does not fit.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message