>[2] http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
^^ It is a must-read indeed. I wish I read it much earlier than a week ago. Julian, as I see you did not reply to [1]. It implies you ignore my suggestions in that thread, or you think they are worse than what you suggest. Jokes aside, I see no way how "manual updates of the latest tested java in all the markdown files" (Julian's idea) could win over "single place to declare the version and let the machine do the substitution in all the .md files" (my idea). Just in case, Julian never asked me if I would volunteer implementing the autoreplacer. Julian, I was scared you quit, and my last hope to heal the community was to organize a call to discuss Ceki's story and try to avoid it in Calcite. I quit as I see there's an impedance mismatch. Thank you for inviting me, that was a nice experience. I learned a lot during these years. I would like to thank Stamatis a lot as he has done a lot for improving the community via meetups, nominating committers, and helping others to get out of the conflicts. The thing I dislike in Calcite community the most is that **very** often people start questioning (or even reject) ideas, they provide no alternatives, and they do not seem to listen. I agree it is wise to give every idea -100 points at the beginning, and then decide if the benefits make the net score positive. However, the community seem to ignore benefits. I absolutely do not want to hear risks like "oh, adding a new language is a serious committment, so we should not add X" or "jira is fine, no changes please". Those are generic risks, and I believe they add no value to the conversations. What scares me A LOT is that I see a very similar pattern in JMeter community (I'm a member of PMC there), however, the number of active contributors is way less than in Calcite, so the friction is way less. Do we really need to discuss the upgrade of junit4 to junit5? Do we really need to discuss adding fuzzing tests (e.g. like in my suggestion to use randomized CI matrix)? Hey, fuzzing is one of the key testing approaches nowadays. Yet Calcite community rejects it and they fear that random failures are bad. Come on. You can do better. Do we even need to discuss that the release notes should be autogenerated (see release drafter)? In my opinion, there's nothing to discuss and nothing to object, and the only question can be "who volunteers" doing that. I often implemented those types of changes, yet the discussions were far from welcoming. Of course, the experience was not bad every day. For instance, "Maven -> Gradle" migration got a lot of positive feedback immediately. https://issues.apache.org/jira/browse/CALCITE-2905 https://lists.apache.org/thread/jw3ovlv5tp3vjcp0o5ztcv8yrzd2okl9 ^^ this was a joy However, as I presented the first prototype, I got a really surprising response: "This is not an improvement because it adds a new Kotlin language in a form of .kts files" https://lists.apache.org/thread/plb3rjypqrwo34qr3o2fdh2qqofx04y9 ^^ this is not fun. I know what I am doing. I am sure the scripts I added are readable and understandable. I know I use up-to-date approaches. Please, what is the reason to mention a generic risk of "adding a new language"? ----- Later I rolled @nullable annotations via Checkerframework https://issues.apache.org/jira/browse/CALCITE-4199 I suggest everybody take a break, think for a couple of seconds and decide if @nullable annotations in Calcite code turned out to be helpful or unhelpful (for both developing Calcite, and using Calcite). >From my point of view, it was super frustrating to receive feedback like in https://lists.apache.org/thread/tyxqydxwbt6lkokgobjok083nxqjrhlx >Vladimir has been trying to fix things that aren’t broken My bad I did not try contacting Julian directly to align approaches to commits, reviews and broken/nonbroken things. Of course, if you consider @nullability annotations harmful and/or useless, all of them can be removed in a matter of seconds (remove annotations; make requireNonNull methods trivial and call "inline method in IDEA"; optimize imports; etc) Of course, it would be better to gradually migrate to Kotlin (it does not require lengthy checkerframework verifier), however I just assumed the idea would be killed no matter what. For instance, Kotlin has the official style guide, so it makes many checkstyle verifications obsolete == much less failures like "you missed a space after comma". ---- Recently I suggested "migrating to GitHub Issues". https://lists.apache.org/thread/m2h13v2p7kowglj73qr4sqn1c3pm8tlq Technically speaking, the results in the DISCUSS thread were not that bad +1 Vladimir Sitnikov +0.5 Zhe Hu +0.5 Jing Zhang +1 Chunwei Lei +0 Michael Mior -0 Josh Elser (no vote) Stamatis Zampetakis -0.47 Jacques Nadeau (no vote, yet the tone was negative) Julian Hyde The VOTE thread was like "everybody rejects": https://lists.apache.org/thread/51dznc2b0yy5sncp56hv3r71nmhtwq9v +1 Vladimir Sitnikov -1 Julian Hyde -1 Chunwei Lei -1 Ruben Q L I absolutely did not care about the exact scores. I was assuming everybody would +1 and we could plan the migration. What I dislike is community resists just because they need nothing more than JIRA. Hey, moving issues to GitHub would make task tracking, commenting, release management, linking, review, and so on much easier to do. It is just nonsense to reject an opportunity when somebody suggests improving the workflow. If the only thing you have is a jira-horse, you would never ask for an automobile. Apparently, the community does not want me or my ideas. Have great holidays. Sorry for the inconvenience.
