Re: usrmerge -- plan B?
Ian Jackson <ijackson@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: