On Tue, 2016-11-15 at 08:36 -0800, Chris Murphy wrote:
> On Mon, Nov 14, 2016 at 4:49 PM, Adam Williamson
> <adamw...@fedoraproject.org> wrote:
> > On Mon, 2016-11-14 at 14:30 -0800, Chris Murphy wrote:
> > > On Mon, Nov 14, 2016 at 1:26 PM, Josh Boyer <jwbo...@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
> cmurf: ok
> For future reference, wait at least five weeks for my short term
> memory recall to fade before playing this particular mind trick on me.
I think I'm playing a mind trick on myself ;) They're really not 'one
big team', that was inaccurate. It'd be better to say that they're used
to reassigning bugs from one to the other. But they actually do
function as separate teams with separate development plans now, albeit
of course they have to co-ordinate major blivet changes.
> 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
> perception.
But we weren't discussing whose job it is to fix it, but rather your
theory that 'anaconda churn' is deleterious.
> > > There's seemingly no lack of resources for an installer that's in
> > > 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.
It is entirely possible, of course, to be 'greatly improved' and still
'excessive'. You didn't argue that the installer is too buggy, you
argued that it hasn't got any less buggy ('stability or blocker bugs')
since Fedora 17. So now you're completely changing your premise.
Still, we've been round this goat rodeo many times, and I know you know
perfectly well why anaconda is susceptible to bugs: because it does a
lot of stuff. Have you considered how many bugs you'd find if you only
tested the same things in anaconda that you can actually *do at all* in
other distributions?
On this specific topic, though, I think there's a reasonable argument
to drop the clever-clever 'make Fedora show up in macOS's graphical
boot menu' trick if there is insufficient commitment to it on the
development side. It's a neat trick, but it does seem apparent that the
blivet change wasn't run by anyone who's familiar with it, which
suggests that either that needs to change or we need to dump it and
just treat Macs more like other UEFI systems, losing the graphical boot
menu trick but gaining some reliability.
> > 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
> > claiming.
>
> 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).
Uh, that's some strange counting you've got there, bub. Your '1', '2'
and '3' are actually all the same single change: newUI. And oldUI still
effectively had a 'guided workflow' and a 'custom workflow'; they were
just presented slightly differently (linearly).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
