incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Vesse <>
Subject Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Date Wed, 24 Jun 2015 07:19:05 GMT

On 24/06/2015 04:12, "Justin Erenkrantz" < on
behalf of> wrote:

>On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik <>
>> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
>> <> 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
>> (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
>> 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
>> 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
>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
>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).


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 ( 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

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


>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.
>Cheers.  -- justin
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message