FYI a thread was started on this (granted not exactly the same point but similar) 10 days ago. I created it so that the issue would get wider oversight by the community. Please see it for additional background so that the folks on that thread don't have to repeat themselves: http://markmail.org/message/hoj6sl6iorbrccrd
My Maven patch has been languishing for quite some time: ZOOKEEPER-1078 - I'd love it if someone were to help me get it over the goal line. Given we've been discussing GIT as well perhaps this would be a good time. Patrick On Sun, Mar 13, 2016 at 10:53 AM, Eric Yang <[email protected]> wrote: > Hi all, > > In the recent discussions on ZOOKEEPER-1604, there are a lot of good points > from both sides who like to keep or remove packaging code from ZooKeeper. > Some of the packaging problems were defects in rpmbuild. There are people > who is interested in ZooKeeper and doesn't like to tackle the ball and > chain of Bigtop. When I started ZOOKEEPER-999, some of the build tools > were lacking at that time. Therefore, it was using a side effect path to > build binaries once and share between RPM and Debian packages. The build > system doesn't work correctly on RHEL 6 after rpm fixed the side effect > path. In ZOOKEEPER-1210, the patch did a short circuit of BUILD_ROOT_DIR > point to top level of build output directory rather than building > directory. This could erase developer's machine, if the build was running > as root. This was quickly realized and a patch has been put forward in > ZOOKEEPER-2007 to fix the short circuit mistake. Unfortunately, > ZOOKEEPER-2007 is never committed. Over the course of many years, > packaging code has been removed in ZOOKEEPER-1604. Everyone has been > forwarded to use Bigtop project. While this works for some people, but it > doesn't work for others. Packaging tools have been improved quite a bit > with Maven, where rpm package building is as easy as describing files in a > .xml file without reverse engineer the tools to do thing backwards. I like > to see ZooKeeper moving to maven, and improve the ability to build rpm > packaging with proper tooling. This will improve the adoption rate. > However, progress would not be made unless the community agrees to review > build patches more carefully. This will only happen if someone is willing > to invest the time to review the project build system, and PMC and > committers are willing to move forward with the proposal. If others put > out patches to move in this direction, please be thoughtful and discuss > with the contributor. After all, the contributor may have spent months to > work on this problem with his personal time. If this is not the direction > that favored by the community, then I also accept the current state of > affair. This message is intended for everyone involved to come to an > consensus whether to accept build related patches. Thank you > > regards, > Eric
