Re: usrmerge -- plan B?
On Wed, Nov 21, 2018 at 06:37:11AM +0000, Domenico Andreoli wrote:
> On November 20, 2018 9:16:17 PM UTC, Adam Borowski <kilobyte@angband.pl> wrote:
>
> >Thus, it seems to me that the plan A for usrmerge has serious downsides for
> >dubious benefits. What about the plan B I described above?
>
> My preferred plan B is the one allowing to release Buster on time with
> most confidence. It's for our users, if we mess up with them the show is
> over.
Yeah, those would be:
• my plan B (no immediate effort pre-Buster), or
• scrapping the whole thing (no effort at any time)
with less confidence:
• making usrmerge Essential (large amount of effort, known issues)
completely, utterly unacceptable:
• status quo -- supporting both
Note that my big objection isn't against usrmerge itself (even though I'm
unhappy about it), it's about having both merged and unmerged systems.
Thus, if we decide to commit to merging, we need to have a flag day and
merge _all_ supported systems. The only technical way to do so I can
think of would be uploading usrmerge set to Essential then immediately
upgrading all buildds. Even binary uploads built on developers' machines
would require checking. But yeah, it's doable.
The slew of build failures and broken packages in the last few days should
be enough to explain _why_ we need to either go all the way in or all the
way out. I bet there's at least an order or two of magnitude more problems
that would appear on rebuilding the world then carefully testing. For
which, a short time before freeze, we simply don't have a chance.
Thus, either usrmerge Essential or not included in Buster -- no middle way.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄⠀⠀⠀⠀ and 1 who narrowly avoided an off-by-one error.
Reply to: