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
