On Mar 28, 2012, at 2:39 PM, Benson Margulies wrote: > 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?
If you want to do it right, build the whole thing from scratch -- nothing but the source code. If there isn't at least one person (or CI bot) doing that per project, we're screwed. > 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? You don't. Fortunately, we require three +1s, so it is fairly hard to trick the whole PMC. > 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? Yes. > In > our role as serving the public good, is this giving the user community > enough information? The user community is not our immediate concern. Downstream developers are. We are only responsible for what we decide to release. > 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. Yes, it's called a -deps package, and individuals occasionally produce them and even redistribute them from our servers (as binaries). Users are warned that binaries are provided for their convenience, and that building from source is preferred for verification. Organizations or individuals that would be offended by (or prevented from receiving) the binaries are fully capable of building their own IF and ONLY IF the binaries do not exist in our source packages. > 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. How is that different from any of our other projects? End users don't compile Java. Hell, most developers don't compile Java. We distribute plenty of binaries. We just don't call them SOURCE. The source is what we review. The source is what we bless. If anyone wants to go further than that, they are free to do so as long as they don't call the result an Apache release. It is a binary package, a user convenience, a download hosted by openoffice.org. I don't care. People have to understand this. There will always be a role for downstream commercial or non-commercial redistributions of Apache products. Why? Because the ASF is incapable of taking on the enormous liability associated with released binaries that are not produced in a controlled environment with a controlled set of tools. ....Roy --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
