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
