On Thu, Jun 2, 2016 at 5:52 PM, Andrew Purtell <apurt...@apache.org> wrote:
> > Our story is made a little more complex due to dependencies on ZK and > HDFS > > More than a little complex because those dependencies in our lib/ need to > be replaced with the local versions in use as installed. > Sure, but complexity shouldn't deter us from implementing some feature that's helpful to users. Solutions like Apache Bigtop already address this. Use Bigtop? > Maybe? Should we document using a Bigtop release in our getting started docs, call it a day? Are we content with pointing users at Bigtop releases? On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: > > > Heya folks, > > > > Per the title, what do you think about generating more easily consumed > > artifacts in our releases? We already do all the hard parts of generating > > binary packages and signing them. Seems like a simple extension to add > some > > additional convenience artifacts. Other Apache projects do this, > including > > hosting release repositories. > > > > Our story is made a little more complex due to dependencies on ZK and > HDFS, > > but I think we could make a strong argument for helping those projects > > produce the same for their users. > > > > IMHO, by not building these (and not providing init scripts, and so on), > > we're basically telling our users they shouldn't use Apache releases in > > prod. > > > > For reference: > > - https://github.com/tcurdt/jdeb#debian-packages-in-java > > - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux > > - https://github.com/OpenTSDB/tcollector/tree/master/debian > > - http://wiki.apache.org/cassandra/DebianPackaging > > > > -n > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
