Russ Allbery writes ("Re: usrmerge -- plan B?"): > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > >> "We ran into some unanticipated issues when we usrmerged our build > >> systems, and we think the way to fix that is to force merge every one > >> of our users' systems." > > > That does seem to be the position that is being advanced. > > I think this is an unfair characterization of the thread, and adds > considerably more heat than light.
I'm afraid I see it as totally fair. (And I do very much hesitate to disagree with you since you are usually right about everything.) > We ran into unanticipated problems *with supporting full portability of > packages between usrmerged systems and non-usrmerged systems*. It was very clear that what was proposed, some months ago, was *optional* usrmerge, which necessarily involves cross-compatibility. It was on that basis that there were few objections. Thus the original design promise from usrmerge proponents, when these changes were last discussed here, was indeed full portability of packages. (Whether the usrmerge proponents realised that or not.) > (And I'm not sure the problems were really that unanticipated -- > that problem is hard.) No doubt there were misgivings in several quarters. I had my own misgivings. But I kept them to myself, in a spirit of not picking an unnecessary fight. After all if something is optional then I can just not opt in. If someone wants to do something that might break their system then why not let them ? They can keep all the pieces. But when I said `unanticipated issues' I meant, of course, unanticipated by the usrmerge designers and implementers. Yes, those problems were unanticipated problems *of full portability* rather than of usrmerge as an abstract principle. But the usrmerge designers and implementers either (i) did not realise that their actions depended on full portability, or (ii) did not realise how hard it would be. That's why there was no plan for how to achieve it. My position as a usrmerge sceptic, of letting them get on with doing their thing, now seems to have been unwise. The idea that it would be optional mutated, without proper discussion, and without a transition plan, into it being the default for new installs. And now there are serious suggestions that to solve this lack of foresight, lack of proper planning, lack of proper consultation, and lack of attention to detail, we should press ahead even faster and make the new scheme mandatory ? On a narrow technical level I can see why that is attractive. But in the wider world, when a particular project team has caused lossage due to poor technical judgement, excessive haste, and at least a perceived reluctance to accomodate feedback, it is rarely the right response to be *less* critical of their plans and recommendations, and push on harder. Especially if that risks alienating objectors who will rightly feel that they would have predicted a mess, if anyone had been prepared to listen to them. I'm sorry to have to put these things this way. This will no doubt read as a criticism of the people rather than of the code, which is difficult and undesirable. But, whether the problems are cultural, or whatever, the dispute here is not only about technical details. We cannot resolve the risk/reward tradeoff of usrmerge with a definitely correct answer because we do not have, and will never have, all the necessary information. We cannot know how many systems in the field would break from a forced usrmerge; even if we were to go ahead with that we would probably never know the real cost. Necessarily this is going to be a matter of judgement and guesswork. The question then: whose judgement and guesswork ? I would like to contrast the approach here to the way that the AppArmor team have conducted their transition. Throughout they have been alert to problems; sought feedback; avoided commitment; and generally brought the vast majority of the Debian community along with them. They have gained not only rough consensus but what looks like real consent (insofar as such a thing might be possible collectively). On the narrower question it must surely be obvious that it is far too late to try to do a forced usrmerge of all systems in buster. Certainly we should not be discussing forced usrmerge as anything but a theoretical option, given that there is not even any transition plan for it and the buster transition freeze is weeks away. The default should be changed back not just in our buildds but also for ordinary new installs. usrmerge proponents can use the time between now and the release of buster to refine their understanding of the issues, do the necessary research, and write a transition plan. We can then have this discussion again early in the bullseye release cycle. If we must. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.