Re: usrmerge -- plan B?
On Thu, Nov 22, 2018 at 11:27:46AM -0800, Russ Allbery wrote:
> > 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.
Given that one of my packages had a bug filed against it that was
caused by usrmerge, and while I *can* fix it, I am also getting a bit
skeptical about trying to rush the usrmerge for buster --- and
**definitely** if it is a mandatory merge. I'd be OK usrmerge being
in buster so long as it has a big huge, fat warning of the form, "if
it breaks your system you get to keep both pieces". So if things
break in usrmerge system on Buster, they would ***not*** be RC, at
least not for the next 3 months.
Post-buster, I agree doing a mandatory usrmerge transition makes
sense, and this should be done very early in the development cycle,
and not at the very end of the development cycle.
> 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).
Agreed, completely. If we leave usrmerge in buster as a "use at your
own risk", then the people who are the most passionate can try it on
their production systems. That will hopefully give us more feedback,
which will significantely reduce risk for bullseye.
- Ted
Reply to: