Re: Action required: Rawhide: /tmp is now on tmpfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2012-06-01 at 12:18 -0400, DJ Delorie wrote:
> I'm going to chime in once to add my thoughts...  It's already way too
> late for me to influence the decision (first I heard of it is "it's
> decided") so my only recourse is to add it to the long list of things
> I have to "undo" after installing Fedora.
> 
> > Sorry guys, this feature sucks.
> 
> +1 on this feature sucks.  Perhaps not for the same reasons.  It's
> mostly for this one:
> 
> > And how is a random user supposed to know this?
> 
> I think any time we make a fundamental change without making the user
> aware of this change and CHOOSING it, we have failed the user.  How to
> fix this?  I don't know, but perhaps...
> 
> * Install should ask the user what they want.  Since /tmp needs to be
>   set up early, it needs to be done in initrd anyway.
> 
> * some post-install GUI/TUI that says "the following systematic
>   changes are now available, please decide if you want them"

http://gnomememes.tumblr.com/post/23820002746/it-should-at-least-be-made-an-option#notes

General Notice: from now on I am going to use that picture as shorthand
for the following screed.

This is a terrible terrible idea, and the reason why has been reasonably
well-understood by several Fedora groups for some time now (I'd cite
especially desktop, anaconda, and QA. Boy howdy, QA knows all about it).

Every time we 'at least make it an option' we double the complexity of
the entire path in question. Double the complexity means double the
maintenance headache, double the QA headache, and at least double the
bugs.

If we go around making every significant change to distro policy
optional in the installer, how many questions are you going to be
bombarded with at upgrade time over the years? On a system that's been
upgraded three times, how many permutations of
$SIGNIFICANT_CONFIGURATION_CHOICE can we now reasonably expect people to
have in place and thus have to test for? How many additional code paths
have we added to the installer (god knows it has enough already; so many
that dlehman and mizmo are having regular Brain Explodey Syndrome lately
just trying to _whiteboard_ the damn thing).

It's this kind of 'everything should be a choice' crap that gives us
hugely overcomplex codebases like anaconda which we can never,
realistically, fully test ever again. (No disrespect to anaconda team
intended; now we've got it, we're stuck with it.) It's also what
regularly gets Microsoft into the soup, and they have development and QA
resources that utterly dwarf ours.

I can see arguments both ways on whether /tmp-on-tmpfs should be our
default and supported config, to be honest. I don't mind whether we go
ahead with the feature or revert it. But we absolutely shouldn't be
asking people whether they want it or not in the installer, and so
implicitly having two equally-supported 'default configs'. That way
madness lies.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux