On Thu, Apr 9, 2020 at 7:21 AM Enrico Olivelli <eolive...@gmail.com> wrote: > > Answers inline > > Il Gio 9 Apr 2020, 05:28 Christopher <ctubb...@apache.org> ha scritto: > > > 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: > > > > Yep > But I'd no one contributes to them it is better to drop them from master. > > > > > 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. > > > > We need two committers +1, not strictly PMCs. > This is setting the quality of our product, > everything we deliver must have the same level.
Are those different for ZooKeeper? I'm not sure what the norm is here. For Accumulo and Fluo, we invite people to be PMC at the same time as committer. (It's easier, because ASF policy is private@ is for PMC, and PMC status is required to vote on releases.) But, I know lots of projects keep them separate... as sort of a tiered merit system. Both have their pros and cons. > > Personally I find good to keep the python binding, and maybe to make it a > sibling of the C client inside the zookeeper-clients module. > I saw recent activity on fat-jar. > > Other modules seem abandoned so no value for me in keeping them. > It would seem kind of wasteful to create a new repo for contrib modules that are already known to be abandoned. They could just be dropped. They can always be restored from the history and be moved into their own repo if there is renewed interest in future. I guess there are several options, to mix-and-match: 1. delete an already abandoned contrib module from the source tree (can restore from history if desired), 2. move a contrib to a new git repo to isolate it from the core build, or 3. keep in the main build... but maybe reorganize, as needed to improve the build in other ways (better maven profiles?). Personally, I think option 2 would be good for the C client and the python binding, as contributors often have expertise in one language over another, and it seems that these wouldn't need to be released as often as the main project. So, they could be more easily maintained and released independently. But, I'm not really in a position to assess the current state of any particular contrib. Until a few were mentioned here, I hadn't even looked closely enough to know how many there were or what they each were for. If I were to help with any of this, I'd rely heavily on current expertise about the state of existing contribs.
