Hi, Julien here, maintainer and main contributor of ifupdown2 since 2016.
> Since Cumulus has been bought by Nvidia, things have changed and > development of ifupdown2 is now done behind closed doors. NVIDIA acquisition of Cumulus didn't change anything for ifupdown2. The team stayed the same and the development cycle stayed the same as well, we always had a 'private' and 'public' repo. Admittedly things have been way slower, since the acquisition we have been very busy and over the past few months I have been dealing with a lot of personal stuff. So, unfortunately the delays are compounding. We are committed to upstreaming our changes and accepting community contributions. Like I said on github, some of the changes are made for Cumulus and are breaking debian's default behavior, so extra work is sometimes required before upstreaming changes. Back in 2016, with Cumulus, we had the goal and ambition to become the default debian network manager, but we realized that the python dependency would be a blocker, so we don't have that goal anymore. And we are happy with the way things are now, supporting our community users and customers. Julien. ________________________________ From: Santiago Ruano Rincón Sent: Thursday, July 11, 2024 2:08 PM To: Daniel Gröber Cc: Martin-Éric Racine; debian-devel@lists.debian.org; ifupd...@packages.debian.org; ifupdo...@packages.debian.org; ifupdown...@packages.debian.org Subject: Re: ifupdown maintenance El 09/07/24 a las 11:25, Daniel Gröber escribió: > Hi Santiago, > > On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón wrote: > > > > Santiago, how do you feel about ifupdown's future maintainability and > > > > feature development? I honestly never looked into why people started > > > > writing ifupdown replacements. I had my own gripes with it so I never > > > > questioned it but I'm happy to hear why we should all rally around it. > > > > > > I've long wondered how we ended up with so many implementations. Team > > > maintenance of just one implementation would make more sense. > > > > > > > For me the reason to work on ifupdown-ng is that it has a better core > > > > design, clean&modern code, an active upstream community, a ***test > > > > suite*** > > > > I fully acknowledge this. After trying to fix some of the ifupdown bugs > > but hitting some design issues, > > Can you elaborate on that point? What are the sort of issues you run into > with the traditional ifupdown design and/or it's maintenance. For example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396. Fixing it is not trivial. > > I think it makes more sense to focus all > > the efforts in just one of the implementations, and since ifupdown-ng > > has all the above mentioned advantages, I'd would be in favor of > > replacing ifupdown by ifupdown-ng... > > Good to hear. > > From the looks of the BTS page I feel like part of the burdon of > maintaining ifupdown is that people just default to reporting any > networking issues there, is that something you see a lot? No, not really. > Perhaps we should have a debian-networking mailing list as Maintainer to be > able to load-share the user-support better? I'd happy with that! > > > > and the potential to fully replace ifupdown without breaking anyone's > > > > system doing it. Full compatibility is not there yet. I'm working on it, > > > > see [1] but I'm optimistic so far. > > > > > > > > [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247 > > > > > > Noted. > > > > ... but it would be *great* to make ifupdown-ng a drop-in replacement > > first. > > Naturally. > > It is pretty close though. The remaining issues I know about are documented > in the GH issue: the locking protocol is sligtly suboptimal (and more > importantly for interop: different), ifstate file is separate and interface > renaming ("rename" statanza) isn't supported. I didn't even know that last > one existed, does anyone use those? Yes, I am aware there are users of the rename stanza. > If you're on-board with transitioning to -ng that should make the ifstate > compat pretty easy since we can freeze the old format and behaviour. > > I haven't thrown -ng at a large legacy setup in anger yet (since I don't > have any), but for regular desktop usage with some mildly custom stuff in > /etc/network/interfaces I hardly notice which ifupdown* I have installed. > > Note: For testing you have to keep in mind to (tranditional) ifdown the > ifaces you want to test first since the ifstate is still disjoint > currently. ACK. [snip] Cheers, -- Santiago
