Hi Lukas, On Wed, Aug 21, 2024 at 10:30:46AM +0200, Lukas Märdian wrote: > This email was intended to first gauge opinions from networking maintainers, > before pushing it out to debian-devel@l.d.o.. All the points still hold and > are fine to be public. But let me at least add the preamble and references > that you dropped from the email quotation.
My bad, I decided late in the editing process to publish this and didn't think to reinstate those sections. > > tl;dr: I'm sorry to say I strongly oppose both removing ifupdown* in forky > > as well as raising netplan to Priority: standard. To move this forward > > without conflict I think we should base the default networking tool > > decision on data not developer opinion. > > In the end it still needs to be a developer decision, because someone needs > to do the work. Otherwise, we would be suffering the same way we did with > classic ifupdown in the past years, as it's becoming harder and harder to > maintain. We need a healthy upstream project and people willing to do the > actual maintenance work in Debian. The way I see it us developers should determine the options on the table, but the community should have a say in the default(s). You said yourself (in private mail) that we should build a community around Networking on Debian, well, this is how I think we should do it. Make people feel genuinely involved in what goes on in our ivory tower. Who knows the publicity might just spawn some (much needed) new contributors. > Can you please elaborate why you're opposed to raising "netplan-generator" > to "Priority: standard"? That's independent of keeping ifupdown-ng installed > in Forky+ and I can't find any explanation about that in your comments below. I'd rather discuss this seperately to keep this thread focused on the survey aspects. Let's discuss this when you publish the summary of the (ongoing) private conversation to d-devel. > > On Tue, Aug 20, 2024 at 12:58:28PM +0200, Lukas Märdian wrote: > > > bluca is requesting ifupdown[-ng] to be dropped from the default > > > installation for Forky, which is sensible, IMO. But we also want to keep > > > it around for a transitioning period (in Trixie), so that people relying > > > on specific if-up/down.d hooks are covered and have plenty of time to > > > migrate to new tooling > > > > NACK. I'm not going to do the work to get ifupdown-ng into shape for being > > the default just to have it removed again that's a ridiculous ask. > > > > That being said I realise that without Santiago's support as ifupdown > > maintainer I don't have much of a procedural leg to stand on in opposing > > this. > > It wasn't an ask, the intention was to have it only if feasible, with > acceptable efforts. Keeping classic ifupdown maintained for a > transitioning period in Trixie would be an option, too, Fair enough. I'm just a bit peeved because we've opened the pandora's box of "we may remove ifupdown" and this has an impact on my ability to find people willing to work on preserving it. > > > I'd like to avoid drama and calling the CTTE to make a decision on > > > our behalf, but rather find a compromise between us networking > > > maintainers. So please let me know if this would work for you or if > > > you have any alternative proposal(s). > > > > Frankly I think the problem we have here is that this shouldn't be a > > technical decision. We should focus on what the majority of our users > > actually want not our preferences. > > It is a technical decision. Utopia/Desktop maintainers made the decision > to use NetworkManager. Cloud maintainers made the decision to use > Netplan. They way I see it they looked at their userbase and decided that those technologies are best for their users. This is exactly what we should do in Debian. Defaults should reflect what most users are going to want and since these different areas of Debian are directed at different sorts of users we can make better decisions here: Desktop? -> nm-applet more important than config file. Cloud? -> cloud-init support more important than anything. server/base-system? -> TBD :-) Who uses the base-system? Well everyone and that's why treating this as a technical decision makes it so hard. There's many conflicting interests and that's why I'm proposing to change the framing. > And I actually talked to [D-I maintainers] about this before, as > I though they'd be in a good position to make this decision – but they > didn't want to. I'm glad they didn't, that would have been a surefire way to get a nasty conflict going. > So I started reaching out to the networking maintainers, about finding > consensus. Look, the problem is we're all biased in this so we can't trust one another (yet), something necessary to form a community mind you, we have to find a decision basis that's more objective to move forward together. > > I propose taking an informal vote on this to gather data on networking tool > > preference among DDs and the wider Debian community to settle > > this. @d-devel has this been done on decisions like these beore? How should > > we go about doing this? Would a GR be more appropriate? > > > > If it turns out I'm alone in wanting Debian to retain it's identity as > > Debian I will (grudingly) step aside on this matter, but in the absence of > > tangible data my current view is that this is not the case and I will take > > appropriate steps to protect that identity. > > Learning from the infamous systemd debate and [quoting former DPL > Stefano], I don't think a GR is an appropriate approach: I agree. Methodologically speaking it's just the wrong tool here. I want us to have a more comprehensive view of what users want than a single winning choice. I used the wrong word for that above actually, I meant we should do a *survey*. I'm hoping we have some survey nerds lurking on d-devel since I don't have any experience with them. Failing that I'd suggest reaching out to find help with designing a meaningful survey. IMO this decision is of the level of importance that we should ask DPL for funding for professional services here if we can't find volunteers with our community's reach. > "GRs should be used for societal and policy decisions. Using GRs for > *technical* decision is stupid. We really need to stop thinking that > every single member of the Debian project, just because he/she is a DD, > has a clue on every single technical matter that go on in the project." Right. > This is not a social nor political decision. It's about choosing a (very > techincal) network stack. That's where your thinking goes wrong IMO. Just because a network stack is a technical thing doesn't imply the decision of which to use must necessarily be technical. They all do the job. To which extent we can have a technical debate over, sure, but there's many ways to reach a decision and while Debian has a clear bias for technical debate that's not always the best choice. > So I really hope we can figure it out between ourselves and avoid > involving the CTTE, or anything else that will further delay a decision > for Trixie. Release dates for trixie aren't even anounced yet and you're already trying to apply time pressure to a discussion. I resent that. Remember: it's done when it's done. This is a big decision let's do it right. --Daniel
signature.asc
Description: PGP signature
