incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Date Tue, 23 Jun 2015 13:21:34 GMT
On Tue, Jun 23, 2015 at 6:11 AM, Jochen Theodorou <> wrote:
> Am 23.06.2015 07:16, schrieb Marvin Humphrey:
> [...]
>>> 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?
>>> 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?
> I am not Roman, but my interpretation in combination with the above would
> be, that if releases require 72h+ and you cannot just upload it somewhere
> and say it is no release, that it takes ages. Something like continuous
> delivery for example looks for me impossible with apache.

I think you are abusing the term 'continuous delivery' a bit.
Keeping the codebase in an 'always releasable state' is quite
different from releasing every commit or every n-th commit.

So I see a bit of nuance here.
The project should not be promoting/advertising non-released artifacts
outside of it's own developer community (e.g. the folks who actually
develop Apache $foo)

The developer, however, may want to show off what he is working on. He
may want to tweet about it, give a presentation or two, invite people
to play with an upcoming feature. He might feature that functionality
at or his own web space. The
difference is that an individual is doing that, and not communicating
as if he is providing downloads/releases on behalf of the project

>>> IOW, I would like to focus on answering the question of how can we
>>> empower our communities to effectively communicate *their* intent
>>> of how *they* expect an artifact to be consumed.
>> They can communicate their intent by voting on a release.
> if every provided download is effectively a release, then you need the
> voting and all before you can release... that takes ages. Imagine you do
> around 13 releases per year. You will be easily busy with voting for over
> two months in total.

It is deliberately 'slow'.
Speaking personally, I understand the frustration with having a robust
CI/CD pipeline, and keeping a codebase always releasable - and then
having a 72 hour voting window (which in my experience is rarely only
72 hours). And I'll also note that this isn't the first project that
has felt those pains. However, that time isn't necessarily about code
quality, it's about the entire community having the opportunity to
make a decision to release or not, rather than a RM making decisions
on behalf of the entire project - which tends to disenfranchise
community, and introduce a strata of being a RM or not into the power

I'll also say, projects don't seem to have a problem releasing
frequently. Tomcat, for instance, pushed out 4 releases in the month
of May alone. It looks like they exceeded 20 releases in 2014. And
there are plenty of projects doing more releases than Tomcat.


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

View raw message