incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Date Tue, 23 Jun 2015 19:22:44 GMT
On Mon, Jun 22, 2015 at 10:16 PM, Marvin Humphrey
<> wrote:
> The distinction is between people who develop the Apache product, and
> those who use the Apache product.

Well, that's part of the reason behind me starting this thread: I think
it is time for us to explicitly acknowledge a third role: an downstream
project developer integrating with Apache *project*. I believe we have
enough evidence that this group of people has unique requirements.

>> How am I supposed to invite all the downstream developers of the
>> world to start integrating with my awesome feature FOO before it
>> gets formally released when our policy makes statement like:
>> "If the general public is being instructed to download a package,
>> then that package has been released."
> Rather than invite them in before you make a release, why not release
> first and then invite them in?

Because I want their feedback during the release cycle, not after. IOW,
I need them to download and integrate with half-baked functionality
that I may be not comfortable putting into a release.

>> Are we really suggesting that I can not present at conference, tweet
>> and otherwise promote the awesomeness of my project based on
>> 'what's coming'?
> Why not release before presenting, tweeting, or promoting?

See above.

>> After all, we have a really good way of communicating that type of intent
>> when it comes to branding: if you want to communicate that Apache
>> FOO is a poddling you MUST refer to it as Apache FOO (incubating).
>> Simple and effective. Exact opposite of our release policy that seems
>> to completely discount labeling for communicating intent. I'm sorry,
>> but a -SNAPSHOT labeling of a version ID communicates as much
>> (if not more) to me as a writing on a website does. Lets just recognize
>> that.
> If artifacts are being consumed by people other than those who develop
> the Apache product, those artifacts need to be vetted and voted.

Like I said -- I'm 100% with you when it come to source artifacts. Can
somebody please explain to me what is a the danger to the foundation
is a [P]PMC wants to make a clearly identifiable non-release artifacts
available to the general public?


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

View raw message