On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote: > > > On Sep 27, 2021, at 2:25 PM, Luca Boccassi <bluca@debian.org> wrote: > > > > Even if that interpretation would work as an excuse to never do > > anything, and I'm not really sure it does, this specification has been > > published in 2014 [0] so even by Debian standard it's old stuff. > > That’s not what I said so. You’re trying to dismiss my opinion as completely invalid now by trying to frame it such that I am against progress. I am not. You dismissed it because it's "new technology": > Not for me, though. Debian has always followed the philosophy to be a universal > operating system, which also meant that we can't (immediately) use all the new > technologies and features that other distributions or upstream projects develop. I simply pointed out that it's a 7 years old spec that saw an entire LTS Debian version (8, we are now at 11) being released and EOL'ed since the time it was published. If this is too new to consider, then so are all Debian releases newer than Wheezy. > > It's > > older than Debian Jessie, which was EOL'd last year. If libparted can't > > keep up with 7 years old stuff that in the meantime was implemented in > > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019, > > and so on, then to me it sounds like a tool in maintenance mode: > > perfectly fine and adequate for existing tools and programs, but not > > quite the best choice for new tools developed from scratch. > > Whether a tool that was developed new from scratch is automatically better is not a given. The burden of proof is on the person trying to introduce the new software, not on the people maintaining the current set of software. > > And claiming that parted is in pure maintenance mode is not true either. It has a paid developer working on the project and is receiving updates and improvements. > > Whether growlight is better and more suitable for Debian needs to be technically proven, not just by arguing that it’s the newer project. > > Adrian Of course. But jumping in and saying "you should use X instead of Y", you can't pretend that nobody asks questions such as "ok, but does libX support this very much related and relevant 7 years old specification that other comparable tools support", no matter how awkward it is for libX. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part