On Mon, Nov 14, 2016 at 4:49 PM, Adam Williamson
On Mon, 2016-11-14 at 14:30 -0800, Chris Murphy wrote:
> On Mon, Nov 14, 2016 at 1:26 PM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
> > If the features were developed and tested during the creation of the
> > release, why would they fail criteria at the last minute?
> Bit rot. That particular code is being modified, and there's no
> testing on hardware affected by those changes before they get pushed
> to the Fedora testing canary. This sort of relationship with an
> upstream is exactly the reason why people refer to Fedora as Red Hat's
> test bed.
> There's also an imbalance in funding Anaconda churn which is mostly
> paid development, vs Fedora QA which no doubt has a much smaller
> budget and to date has largely depended on unpaid contributors for
> this testing.
BTW, you're acting under one fundamental misconception here: the change
that broke this was in *blivet*, not anaconda. Those development teams
are now quite significantly separate.
BTW, within the last couple of weeks you and I had a neat conversation
that went something like this:
cmurf: pretty sure this is a blivet bug, not anaconda
adamw: meh, it's all one big team, they can sort it out and change the
component if necessary
For future reference, wait at least five weeks for my short term
memory recall to fade before playing this particular mind trick on me.
But hey, in 1033778, a big part of its years long existence can be
attributed to buck passing among the fiefdom of components. If there's
a fundamental misconception, it's that users understand the 'get your
bug off my lawn' mentality. These are Fedora bugs. That's the
> There's seemingly no lack of resources for an installer
> continuous development without any apparent improvement in usability
> or stability or blocker bugs since Fedora 17.
This is completely false. The stability of anaconda has *greatly*
improved since Fedora 17.
I did say apparent, although I should have been more clear by using
"apparent to me" since it's based on my own bug reporting experience.
Better qualified, even if it were true that I filed 50% fewer bugs for
Fedora 25's installer, I think it's still excessive rather than
greatly improved. In a decade I've experienced fewer bugs against all
other installers combined, than the bugs I've filed against Fedora's
in any single cycle.
> More canaries of any sort is not going to help find the source of
> problem and the solution. What's needed are people who can do the
> proper kind of reporting, and there simply aren't enough of those to
> keep up with all of OUR weird changes and code churn.
I think before you keep up this line of argument you should provide
some concrete examples of the 'weird changes' and 'code churn' you are
OK well the most obvious would be the four installer UIs in 5 years,
should blivet-gui get integrated in Fedora 26. The old bottom UI is
dumped (1), and replaced with automatic partitioning (2) and custom's
top down UI (3). Then the idea becomes the top down UI isn't doing
what users want so add a new bottom up UI (4). That's what I mean by
churn. And I think it's weird to be building yet another sky castle
before fixing data loss inducing bugs and persistent sources of UI/Ux
mactel-boot is clever and pretty, but it is weird because a.) it
causes Macs to be treated differently from other EFI systems and b.)
no other distro is using it c.) people don't understand it. It
increases the foot print for bugs and other confusion.