Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
> That's the reason why I'm inclined to try to stay out of the decision as
> much as possible and leave it to the GNOME maintainers, who know
> considerably more about the system than I do.One might as well say that we should leave it to the users, who know considerably more about their system. It is important to remember that fundamentally the dispute here is not between me and the gnome maintainers. I don't have a dog in the fight - or at least I didn't until I called out the maintainers' mistakes. (I don't have gnome or gnome-core on any of my systems and I do have network-manager on my netbook.) The complainants are certain users who have decided against n-m. The question is whether the disbenefit to those users outweighs the alleged benefit to other users who previously decided against n-m but who in the opinion of the gnome maintainers would be best served by reinstalling n-m. It would take an extremely convincing argument for me to conclude that we should overrule an explicit decision by a user in favour of a blanket decision by a maintainer. This is particularly true when these users have already decided not to take the maintainer's advice. By the decision not to install n-m, those users have already overruled the maintainer for their own systems. To say that we think the maintainer knows best is going against the clearly expressed opinion of a user who has deliberately deinstalled n-m. And, as you say, reinstalling n-m during the upgrade is deeply problematic. At the very best it will have no beneficial effect until the user take explicit action to reconfigure their networking to use n-m. There is of course no particular reason why it would be difficult for a user who changed their mind to reinstall n-m as and when they felt like it - under conditions where they are prepared for a failure of their networking and have the time and inclination to reconfigure. Under these circumstances I think it would be wrong of us to countenance the maintainer's escalation in the war of competing preferences. > That's the reason why I'm inclined to try to stay out of the decision as > much as possible and leave it to the GNOME maintainers, who know > considerably more about the system than I do. While the current situation > is not the compromise that I would have proposed, it does feel like a > workable compromise (in conjunction with release notes), and I do think > it's valuable to compromise some in situations like this. I think this proposed compromise is a compromise between the rights of our users to configure their systems the way they want, and the desire of the GNOME project and its supporters to make a strong declaration about the status of Network Manager. The claims that n-m has improved have to be seen in the context of a persistent and long-running battle between that strong declaration and users' desire to set up their systems the way they prefer. The reason there is so much heat here is precisely because of that long-running battle. But, frankly, in that battle I think there is a right side and a wrong side. I don't think we should compromise on the principle that the software we ship should honour the explicitly stated wishes of our users. > The tension in the discussion is making it very hard to hold that > position. People on all sides of this discussion seem to be pushing it > towards becoming a referendum on the legitimacy of the Technical Committee > rather than a method for arriving at the best all-around compromise for > both GNOME users and the project, and that's making me really > uncomfortable. A referendum on the legitimacy of the TC would surely be a GR. I'm just trying to do the right thing by the users. That means that when the user chooses to disregard the maintainers' advice, we should not allow the maintainer to now impose that advice simply because the maintainer claims that the basis for the user's original decision is no longer true. That is a decision for the user, not the maintainer, to make. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
