On Wed, Apr 8, 2020 at 2:01 PM Damien Diederen <ddiede...@sinenomine.net> wrote: > > > Hi Christopher, > > > I am just curious if anybody has thought about, or perhaps discussed, > > the idea that the projects in the zookeeper-contrib folder should be > > in their own separate git repos? > > We were discussing this a few days ago: > > https://github.com/apache/zookeeper/pull/1068#issuecomment-607160440 > > My (only) concern was that I wouldn't want to see contribs *even more* > abandoned than they are now:
That's a fair concern. It is always sad to see code get abandoned. Moving them out won't solve a "lack of interest" problem. Apache is composed of volunteers... and sometimes interest in a project withers. But, it can help organize whatever remaining (or future) interest there is by decoupling the contrib and presenting it as a smaller, more focused project. > > >> While I wouldn't be opposed to moving "unpopular" bindings to their > >> own repository, it would probably only make sense to do so if merge > >> rules are somewhat relaxed—as I suspect it would otherwise be even > >> more difficult to meet the "two PMC approvals" threshold. That already seems like a pretty high bar to me, even for the main project. It's definitely more strict than the other Apache projects I've contributed to. I can see how it could be a problem if there is diminished interest in these contribs. The PMC would have to decide how they want to approach that. > > But whatever the outcome is: > > >> In any case: I am willing to be automatically marked as a reviewer > >> for (at least) the zkperl and zkpython "contribs." Do we have such a > >> mechanism? I see that GitHub implements some such mechanisms (1, 2), > >> but I'm not sure how applicable they are to our case. Never hesitate > >> to ping me manually! > > > I'm asking because I've been looking a lot at the build, trying to > > find ways to improve it, and I think this might be a nice improvement > > to streamline the core ZooKeeper build. This can help side-projects > > succeed or fail on their own merits, rather than be bound to the core > > project so tightly, and it could make it easier for contributors to > > know where to contribute, by making each independent component smaller > > and easier to navigate through the code. > > Mostly agree—except that I would subsitute "popularity" for "merits." > (Which may or may not change the conclusion.) Yes, popularity. :) > > Cheers, -D
