In my experience properly maintaining any distribution packages is a large undertaking. I haven't seen an individual component project like ours do a good job of maintaining proper rpm/deb packages for itself. I don't know that I'd -1 someone wanting to do the work in our community, but I'd be surprised if there was a net benefit over e.g. BigTop.
The problem with BigTop is that the version of HBase provided there will only keep up so long as our community is investing the time there for it to happen, naturally. > 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. I do agree with this sentiment, FWIW. not providing good last-mile-to-deployment tools is a recurring issue we have. 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 -- busbey
