Thank you all for this discussion. I would go with: - drop contrib modules - keep fat jar and python - move python in zookeeper-clients directory - move fat-jar to the top level directory, next to binary assembly package (but we won't release it in binary form and we won't deploy to maven central). We should keep a maven profile to include it, it is quite heavy and it is useless for most of the cases - make this change only for master: 3.6 and 3.5 will stay the same - old stuff is still on git history
We can split the work in a few steps and give time for people to react to the patches before committing them. Christopher if you have times to create the patches I will be happy to follow your work and help Best regards Enrico Il Sab 11 Apr 2020, 06:34 Christopher <ctubb...@apache.org> ha scritto: > 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. >
