incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Tue, 27 Mar 2012 23:16:58 GMT
On Tue, Mar 27, 2012 at 12:57 PM, Jukka Zitting <> wrote:
> Let's decouple this thread from the specific issue of the ManifoldCF
> release. There's a long tradition of Apache releases like the ones
> ManifoldCF is producing, so turning this suddenly into a blocker is
> IMHO bad business, especially since no legal issues are involved (this
> is about Apache policy). If we do come to the consensus that releases
> like this are contrary to Apache policy,

*jaw drops*. Huh?

But, but, but. But! It's called open *source*.

I am honestly just really surprised that this can even come up as a
discussion topic. It's such a core concept that source releases are,
well, *source* releases, everything is built on top of it. It's not a
policy thing, it's a definition thing.

The one case I can imagine that might be sort-of ok is if you ship a
release with an ant-based build that includes a custom task, and in
the source release of your entire project you *also* include a binary
version of the custom task, so lazy people (or those without a working
bash, or whatever) can avoid running your bootstrap script. (and
simlarly, s/ant/maven/, s/task/plugin/, etc). But there's obviously
better ways to do that stuff (target that compiles task, taskdef for
task in next target, that kind of thing).

> then affected projects should
> be given a reasonable amount of time to adapt.

Uhm. Normally I'd want to take a similar approach. But. But. But! Open
*source*. It's so fundamental to what we do.

This seems exactly the reason why we have incubation disclaimers: so
we make clear to our downstream users we might be making some mistakes
like this, and so that we can then be agile in fixing it. "Whoops,
made a mistake folks, no downloads here, stand by while the podling
makes a new release...".

I'd think that when we find a problem like this after a release is
published, we (we as in the PMC, this is not a task to shove onto
infra!) should immediately explain the problem and then immediately
yank any existing incubation releases that have an issue here. No
grace period, no voting, no discussion. Just fix it.

That said, I'm not aware of us actually having such a release out there?

How to deal with this stuff for TLPs that got it wrong, well, I guess
that's a conversation for (a) different mailing list(s).


Leo, still trying to pick his jaw up from the floor

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

View raw message