Bug#688772: gnome Depends network-manager-gnome
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.
Reply to: