On Fri, Apr 10, 2020 at 12:56 PM Benjamin Reed <br...@apache.org> wrote: > > did you mean to mention the c client in the list of things to move to > another repo? it's not in contribs right now.
No. That was a mistake of mine, based on my understanding of a previous response in this thread. However, it might still be a good idea at some future point, if it doesn't change frequently. > > i think it would be nice to clean the contrib a bit. i don't really > support moving it to a separate repo. the nice thing about keeping it > in the same repo is that when there is a change that might break > contrib, we can catch it. Breaking changes can be caught in other ways also, with CI testing, for example. Also, playing "devil's advocate" here, that diverted work to catch and fix it isn't free. If the contrib is abandoned, the extra work diverted might not be worth it the effort. > > one problem with "cleaning" contrib is that different people have > different perspectives on the usefulness. for example, i only use > fatjar files. it makes everything easier when using zookeeper. on the > other hand, i never use the python binding; i wouldn't recommend it to > anyone either: kazoo is just too good! This is really the main reason to separate stuff into separate modules. This allows those self-selected groups of people who care more about one component than another, to focus their efforts on the thing they care about. > > having said all that, i'm extremely happy you are working on this > Christopher! your maven cleanups and enhancements are great! Thanks. If there's a silver lining to this global pandemic we're all living in, it's that I've had a bit more time away from $dayjob to contribute to projects I've wanted to help out with for a long time. I hope to continue to contribute more. ZooKeeper's a great project. As for the contribs... I don't actually know how much I'll be helping with it at the moment. That really depends on the decisions the PMC makes on what actions should be taken. I can help do the work if the discussion turns into a resolution for action... but until then, I'm happy learning from the conversation, and would be okay with taking no action on any of the contribs if that's what is desired. :) > ben > > On Thu, Apr 9, 2020 at 7:57 PM Christopher <ctubb...@apache.org> wrote: > > > > 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.
