incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
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?

Karl

On Tue, Apr 3, 2012 at 11:00 AM, ant elder <ant.elder@gmail.com> wrote:
> On Tue, Apr 3, 2012 at 3:43 PM, Karl Wright <daddywri@gmail.com> wrote:
>> On Tue, Apr 3, 2012 at 10:33 AM, ant elder <ant.elder@gmail.com> wrote:
>>> On Tue, Apr 3, 2012 at 3:18 PM, Jukka Zitting <jukka.zitting@gmail.com>
wrote:
>>>> Hi,
>>>>
>>>> On Tue, Apr 3, 2012 at 3:52 PM, Karl Wright <daddywri@gmail.com> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message