Shading is the mother of anti-patterns and a nightmare. IMO, it should only be used as a workaround in the most dire situations.
Gary On Sat, Nov 16, 2024 at 10:45 AM Gilles Sadowski <gillese...@gmail.com> wrote: > Hi. > > Le sam. 16 nov. 2024 à 16:17, Gary Gregory <garydgreg...@gmail.com> a > écrit : > > > > On Sat, Nov 16, 2024 at 10:06 AM Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > Hi. > > > > > > Le sam. 16 nov. 2024 à 14:45, Emmanuel Bourg <ebo...@apache.org> a > écrit : > > > > > > > > Le 15/11/2024 à 17:08, Gary D. Gregory a écrit : > > > > > FYI: The revert has now been implemented with the exception of > keeping > > > the change from Commons Codec Base64 to Java 8 Base68. > > > > > > > > Hi Gary, > > > > > > > > I don't understand your stubbornness on this subject, Commons > Compress > > > > had zero dependencies for over 10 years, the general sentiment from > the > > > > recent discussions seems to point toward avoiding such a dependency > > > > bloat, your change was never discussed on the list, it broke Commons > > > > Compress (COMPRESS-666 [1], with a highly ironic bug number), and the > > > > project was even forked due to this issue. > > > > > > > > I highly appreciate your dedication to maintain the Apache Commons > > > > projects, but you've made an error here. It happens, that's not a big > > > > deal, but please listen to the community. > > > > > > > > Would you accept to resolve this with a vote? > > > > > > Both sides have something in their favour; you are right in > > > the short term, Gary is right in the longer term. [IMO] > > > Wouldn't the project benefit from a common policy on how > > > to deal with such issues (rather than be divisive, once more)? > > > > > > [I'd go even further that, by not delving into the crux (no policy) > > > of this kind of issues, we create "opportunities" for infighting, > > > based on who is more legitimate (so-called "meritocratic") to > > > make changes or revert them. In that respect, both sides > > > have again something in their favour.] > > > > > > I've proposed (and have done so more than twice in the past) > > > to examine a way out (i.e. define an official hierarchy among > > > the "Commons" components), but you both have ignored it. > > > > > > > Hello Gillies, > > > > I've not ignored > > OK, sorry; by "ignored", I actually meant, "no action" such as > "Let's do it" or "No, because ...". > > > and even offered my view in these threads: I see that > > there are low-level components like IO and LANG, and higher-level > > components like VFS, CONFIGURATION, and COMPRESS. > > > > We could draw a picture I suppose. > > Indeed; but work like this should follow the acknowledgement > that a policy should indeed be put in place in that regard. > As in we all decide which components _must_ have zero > dependency (and why), which could depend on an internal-only > dependency (to avoid having to "shade"[1]), which must depend > on other "Commons" (rather than copy/paste code from them), > which are expected to depend on external libraries. > > Gilles > > [1] Or maybe, the policy would prescribe that shading from this > internal-only component is a required step for any release of > a component that includes functionality implemented there (so > that any intervening security fix is performed in a single place). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
