Roy, 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
