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