On Sat, Jun 20, 2015 at 3:15 PM, Sean Busbey <bus...@cloudera.com> wrote: > It's problematic to reference non-public lists that other folks can't go > follow along with.
What's this supposed to mean? I can't really change the fact that this discussion *already* happened on the list that not all have access to. Still I felt given your membership status it was relevant to mention it (since you have no problem accessing it). Same applies to all the other mentors here. Not sure what you find 'problematic' there. > I re-read that thread on infrastructure@, and I don't > see anyone bring up the matter of nightly builds. All the support is around > publishing docker images that contain released software. I don't understand what gave you that impression. I wasn't really subsetting that discussion to the 'images that contain released software' but was asking an open ended question. > AFAIK, the current policy would apply equally to SNAPSHOTs put in the Maven > repo. That is, those SNAPSHOT artifacts are for the development community > *only* and they must not be pointed to for downstream users. This is where we have different opinions interpreting the policy. The best way to resolve this disagreement is on general@ and not a poddling mailing list. Once this disagreement is resolved either of us can follow up with a poddling. > Your point in that private list about Maven Central and Docker Hub is very > relevant; I agree they are essentially the same kind of > publish-to-the-public access point. While we have SNAPSHOT artifacts posted > to the ASF maven repo, that repo is not mirrored into Maven Central because > it would be against foundation policy. > > What the Geode PMC is currently doing is the equivalent to a project > publishing the SNAPSHOT artifacts to Maven Central. I hope we are all in > agreement that that would be inappropriate. Actually no we are not. And like I said an appropriate place to resolve this disagreement is on general@ at this point. But just to record it here, the reason I disagree with your argument is that I see nothing in our policy that would support the claim that it makes any difference of whether the artifacts are published on ASF managed INFRA or not. What I see is this: =============================================================== "If the general public is being instructed to download a package, then that package has been released." =============================================================== it matters not where this package is residing. > I have also seen lots of folks successfully use Docker images to do build > automation. That's not related to the matter at hand, I agree. I was only using it as an example of something that a project may want to publish under its 'official' (whatever that means) account on Docker hub. The project will be, then, fully within its right to communicate to the 'general public' that the recommended way of building it is: $ docker run FOO My point here is: even when such a communication happens, I hope we both can agree that the build related docker container should NOT be considered as part of a project binary release (and shouldn't be covered by ASF's release policy) > which is publishing > to the Docker Hub. Nothing other than Geode showed up in a superficial > search for nightly builds from ASF projects. Take a look at https://registry.hub.docker.com/u/bigtop/slaves/ Those images are supposed to be updated every time the build infra (as defined by Bigtop's puppet code) changes. IOW, the content of these images is keyed off of CI that triggers from the unreleased Bigtop code checked in. > The tweet from the Geode PMC, the blog post, and a quick search of twitter > for additional references makes discussion of possible uses of docker and > the hub irrelevant. The docker image on Docker Hub is of non released > software and is being used outside of the development community. Like I said we have different interpretations of 'development community'. Yours is narrow, mine includes downstream developers integrating with the project. > It needs to be removed. We may very well end up doing that, but not until there's a legitimate discussion clarifying the situation. > I encourage more discussion of this on general@incubator (though the > release policy would have to go to legal-discuss), That is actually not clear to me. From a legal perspective ASF is all about open *source* development. Having seen too many "we don't even recognize binary convenience artifacts" threads over the years I won't be surprised if the issue gets punted back to the board/comdev. I'd be very curious to see how it shakes out, sine I believe it is high time we finally clarify this part of ASF's policy once and for all. Once again, thanks for bringing the inconsistencies to light -- I am very much looking forward to our productive discussion on general@ Thanks, Roman.
