incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Date Wed, 24 Jun 2015 03:12:56 GMT
On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik <roman@shaposhnik.org> wrote:
> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
> <Ross.Gardler@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).

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


Mime
View raw message