This issue points out that we need to have a serious discussion about how we are or aren't communicating.
On or about May 31 a number of us found our wifi broken. Turned out to be an upgrade to networkmanager forcing implementation of iwd. Enough people lost wifi to provoke a group discussion on IRC @ #openmandriva-cooker. We as a group agreed that iwd was not ready to implement by default in OpenMandriva because there are to many chip sets that won't work with it at this time. These 2 commits:
Please get that. The contributors group on IRC discussed as a group and agreed as a group on something. Both developers and QA-Team members were present and in agreement. This was a group decision not one person acting alone.
Fast forward to yesterday, July 18, and when I go on IRC there are people discussing this again? What? "We already discussed this and agreed on this!" Well it turns out this change got pushed again. Apparently without any discussion or agreement that I'm aware of. There was a commit 16 days ago on github but I would have thought that since no one agreed with that and the issue was not discussed the commit would and should sit there until it was discussed and either agreed on or disagreed on. In other words I thought the published policy would be followed. The published policy does include "waiting for others to accept it".
What published policy? This: https://wiki.openmandriva.org/en/Policies/Repository_Policies
Which includes the following:
= Cooker =
Cooker is an experimental branch that can break at times. Most things are ok to do here, including updating to a beta version or even a git/svn/cvs/hg/whatever snapshot of an upstream package.
To make sure you don't "surprise" other developers by breaking everything for them, major changes need to be coordinated by either:
* bringing them up in a TC meeting
* sending a pull request on the repository and waiting for others to accept it
* sending an email to the cooker ML and waiting for others' positive reply
Changes that need coordination include, but are not limited to
* switching out a major system component for something else (e.g. Xorg -> wayland, Qt 5 -> Qt 6, wpa_supplicant -> iwd, systemd -> any other init system, ...) -- any such change should be tested in a personal repository first.
* update that will require a load of rebuilds (e.g. updating libpng to a version with a new soname)
* dropping a package used by many things (e.g. dropping qt5 when qt6 is out and has been stabilized)
* changes that are likely to break other people's hardware
Cooker is usually open for all types of development, but can be frozen at some times to consolidate efforts on one branch."
IMO changes like "(e.g. Xorg -> wayland, Qt 5 -> Qt 6, wpa_supplicant -> iwd, systemd -> any other init system, ...)" should not be discovered by users or contributors after a system update. This stuff really, really, really, needs to be discussed on and agreed on as a group. To do this we need to all be communicating in the same place.
We might also need to consider tightening things further and make it policy that such "major system component" changes simply should not be made until they are announced in TC-Meeting so people are not surprised by such changes. The advantage to announcing these and other changes in TC-Meeting is that there are written logs which one would hope would eliminate any confusion or disagreement.
So for NetworkManager we need to again revert the changes made to what we as a group agreed upon. Agreed because iwd still does not work with a lot of chipsets. If this is something to be tried in Cooker so developers can work on it then this should be discussed and announced so others using cooker aren't surprised after upgrading a package as happened to many folks yesterday.
And as a group we need to discuss the absolute paramount importance of following this documentation: https://wiki.openmandriva.org/en/Policies/Repository_Policies, if not in fact modifying this as suggested to include announcing major changes in TC-Meeting.
Note: The statement or comment "iwd still does not work with a lot of chipsets" is made because this is what more than one developer has told me.