incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: Question about downloading binaries
Date Tue, 03 Apr 2012 15:04:46 GMT
It sounds like I wasn't clear enough.

The proposal is for the following release artifacts:

(1) A source-only tar
(2) A source+binary dependencies convenience tar
(3) A binary tar

This is instead of:

(1) A source-only tar
(2) A binary dependencies convenience tar
(3) A binary tar

Hope that helps...  The question is, will Roy (or anyone else) be
unwilling to vote for the first option?


On Tue, Apr 3, 2012 at 11:00 AM, ant elder <> wrote:
> On Tue, Apr 3, 2012 at 3:43 PM, Karl Wright <> wrote:
>> On Tue, Apr 3, 2012 at 10:33 AM, ant elder <> wrote:
>>> On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting <>
>>>> Hi,
>>>> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright <> wrote:
>>>>> Our mentor(s) are pushing strongly for a source release (which
>>>>> contains the upstream patches), plus a "lib" release, which is to be
>>>>> overlaid on the source release to allow it to build.
>>>> I wouldn't call it "strongly", rather as just one possible solution
>>>> that can be implemented in the short term without significant impact
>>>> on the existing codebase. The other alternatives being suggested
>>>> seemed quite a bit more complicated.
>>>>> I much preferred a source release and a convenience source+lib release,
>>>>> but that caused significant objections, so I gave up.
>>>> My main objection here is that the official source release should be
>>>> readily buildable. If the build instructions are essentially "take
>>>> that other package and build it instead", then IMHO in practice that
>>>> other package is the one that's being released.
>>> It could still be readily buildable because it can just document how
>>> to overlay the lib folder from the source+lib release onto the src
>>> only release. In practice probably everyone would just use the
>>> source+lib release anyway but so what.
>>>> Personally I'd be fine with the source package containing required
>>>> binary dependencies, but since others will likely -1 release
>>>> candidates like that, I don't see how a convenience package like that
>>>> would pass review.
>>> IMHO given that ManifoldCF is a little unusual that makes sense to me too.
>>>   ...ant
>> I like the "additional instructions" idea.
>> I would love to get a show of hands for a source+lib convenience
>> release rather than just a pure lib release.  Anyone want to provide a
>> +1 for this approach, or more importantly, a -1 if you have
>> significant objections?
> Well the documented rules are that releases can't be veto'ed so you
> just need three, but from my reading of all this the main problems are
> the comments from Roy which i expect given the climate in the
> Incubator these days might make three hard to get:
> "Organizations or individuals that would be offended by (or prevented
> from receiving) the binaries are fully capable of building their own
> IF and ONLY IF the binaries do not exist in our source packages."
> and
> "Our releases are absolutely forbidden to contain anything other than
> the open source code that is in our vcs-of-record"
>   ...ant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message