About maven, I still miss it. Arguing is pointless If all you have is a hammer, everything looks like a nail
Regards! Aron Tao Vladimir Sitnikov <sitnikov.vladi...@gmail.com> 于2021年12月23日周四 07:10写道： > >[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. >
