zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Debian packager orphaning ZooKeeper
Date Wed, 15 Jun 2011 18:40:15 GMT
I have been corresponding with the Debian developer community.  Their major
beef with ZK is that it doesn't compile on MIPS architecture using gcj.  The
package as proposed says that the default java is acceptable and on MIPS
this is gcj.

Clearly there is a major disconnect between what Zookeeper is, what it
requires and the current proposed Debian packaging of same.

My major question is: do we care?

Literally, is there anybody out there who would be positively impacted by
having a debian package for Zookeeper?  (nobody can be negatively impacted
at this point because there isn't any official debian package for ZK).

If there is somebody whom such a package would help, then I say we do care
and somebody ought to step up to maintain and fix this package.  Right now,
just restricting the package to use java 1.6 should be enough to move
forward.  Behind that issue, there is a moderate bug in the way that a cron
job is set up to clean up logs, but isn't unscheduled.  Beyond that, my
guess is that the level of effort should be no more than tracking production
ZK releases.

Is anybody out there?

On Wed, Jun 15, 2011 at 7:32 PM, Gustavo Niemeyer <gustavo@niemeyer.net>wrote:

> (...)
> > I am really sad this issue being brought up on dev list again. I hope
> > we can have more fruitful conversations than "code quality" on the
> > mailing list.
> Stability and code quality are two different aspects, and I for one
> think the mailing list for the project itself is the right place to
> have these conversations.  You don't have to agree with the points
> made, but being so offensive towards even bringing the concept up
> feels a bit like validating some of Thomas' point, interestingly.
> --
> Gustavo Niemeyer
> http://niemeyer.net
> http://niemeyer.net/blog
> http://niemeyer.net/twitter

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message