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
