On 24/06/2015 04:12, "Justin Erenkrantz" <justin.erenkra...@gmail.com on behalf of jus...@erenkrantz.com> wrote:
>On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik <ro...@shaposhnik.org> >wrote: >> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH) >> <ross.gard...@microsoft.com> wrote: >>> There is nothing preventing "clearly identifiable non-release artifacts >>> available to the general public". Many projects make automated nightly >>>builds available for example. >> >> This! Honestly this has always been my personal interpretation of the >>policy >> (although now that I'm re-reading it I see how it could be interpreted >>in a >> radically different way). >> >> IOW, I've been mentoring a lot of poddlings and advising them that as >> long as they go out of their way to label 'nightly' artifacts as NON >>RELEASE, >> DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to >> "general public" (*). I have always though that, for example, -SNAPSHOT >>version >> designation is enough to communicate that type of intent. Same as >> SNAPSHOT/NONRELEASE tag on Docker image, etc. > >I agree. As long as the version designation of the artifact includes >-SNAPSHOT or -DEV or whatever, I think that's sufficient to qualify as >a "clearly identifiable non-release artifact". > >FWIW, httpd always had nightly tarballs available for consumption and >testing. > >I do think that the threshold is that it needs to come from an >automated process blessed by the [P]PMC. If it requires a human to >publish the "nightly" into the distribution channel, then I think >that's probably where the line gets crossed and our voting rules >apply. > >Nightly builds shouldn't be "easily" found - except deep inside >developer-facing documentations. All obvious materials should point >at the official, blessed releases. But, it's important to provide a >channel for downstream people to test trunk/master/develop (whatever >shiny name the project calls it). +1 Personally I think the policy should be clarified such that nightly builds MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs repo, committer web space etc). As soon as you start putting them on external services like DockerHub then they are potentially widely visible to the general public. Going back to the example of libraries published as Maven artifacts for those projects already publishing SNAPSHOTs these only get published to the Apache Nexus server (repository.apache.org) and are not synced to Maven central. People who want to consume those artifacts have to explicitly configure their Maven setup to enable Apache SNAPSHOTs. For me this is a sufficient barrier to distinguish between "developers" and "users". FWIW if someone has made the effort to join the mailing list and report a bug which we then want to ask them to test a fix for then they are clearly in the developer category (or more accurately they are a contributor) and I would have no problem to pointing them to the nightly builds so they could do this. However putting stuff out there on an external hosting service that is widely accessible seems to go against the spirit (and likely the letter) of the policy Rob > >In today's day and age, producing Docker-like thingys is akin to >producing RPMs. I won't go into why I think the centralized Docker >Hub is a huge mistake - it's simply how you consume Docker thingys. I >do wish that we could point folks at a specific Docker registries (a >la an apt or yum repos), but having a single global registry is how >Docker, Inc. apparently thinks that it'll justify its valuations. >Sigh. > >Cheers. -- justin > >--------------------------------------------------------------------- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
