Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > 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.)
This is a much better summary of the thread, and I wish that you would have said this instead of claiming incorrectly that those same people are the ones advocating for a full merge of all systems. *I've* been one of the people advocating for that on this thread, and I've not previously been involved in the usrmerge proposal at all. I'm not sure how many of the other people advocating it have been involved in the project. Neither Marco nor Simon have taken a position that I've seen, and so far as I can tell are still interested in the optional approach. I'm stating the advantages of fully converting Debian to merged /usr for engineering reasons: I don't think the existing optional migration is going to work very well or be supportable. On this point, I'm *disagreeing* with the usrmerge maintainer, who holds the opposite view. Can you see from this why I think your and Michael's collapsing of nuance into a claim that the usrmerge proponents are trying to react to a setback by moving faster is unfair and harmful? It's reducing a more complex discussion to a simple us vs. them narrative. > 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. I generally agree with this. I also don't think this is particularly unusual, or should be considered some sort of major failing. A lot of us, particularly on volunteer projects, are not going to get our analysis right the first time. That's why we stop, and think, and adjust when something unexpected goes wrong, like now. > 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. I agree with wanting more discussion and more of a plan before making it the default for new installs, and I'm skeptical this is a good idea for buster. > 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 ? Again, I think you're mixing up two separate issues in a way that adds more noise than clarity. There are two separate decisions here: * Do we want to back off from supporting an optional switch and instead pursue converting all Debian installations to merged /usr? * If we do want to do that, *when* should we do that, and what should the timeline look like? The question of "faster" is about the second point, not the first one. Personally, I think I agree with the comments here that it's too late to do this for buster, and if we're going to work towards fully merging /usr, this is something to tackle for buster+1 (preferrably by significant testing very early in the cycle). The first question is still open. Various people have stated their opinions, but I'm not sure we're having a proper debate about it because it keeps getting mixed into other issues, such as people's opinion of the planning and communication strategy of people working on usrmerge, or what the timeline could look like. I understand that those are all issues that matter. What I'm objecting to is (unintentionally, I think) muddling them all together into a giant, upsetting mess of conflict. I don't blame you for finding that upsetting -- when everything is mixed together like that, it's all very upsetting! That's why we need to break this down into separate points of disagreement, separate the engineering decisions from the communication and community decisions, and figure out where we actually disagree and what the most constructive path forward is. > Necessarily this is going to be a matter of judgement and guesswork. > The question then: whose judgement and guesswork ? Are we not a community? We're providing input as a community in this thread, providing some judgement and guesswork from lots of different contributors. I agree that at some point someone needs to step forward to pull that all together into a set of possible strategies to move forward, but I don't feel like we've even separated the strands of things we're arguing about yet, let alone clearly explored the options. > We can then have this discussion again early in the bullseye release > cycle. If we must. That idea makes me wince. This will just result in the same thing happening again. Let's have the discussion *now*, when the problems are fresh in our mind, and then defer *action* to early in the bullseye release cycle (which I suspect is likely to happen anyway given how long it usually takes us to sort through questions of large migrations like this). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>