[Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs

John.Florian at dart.biz John.Florian at dart.biz
Mon Feb 24 13:48:20 UTC 2014


> From: awilliam at redhat.com
> Date: 02/21/2014 17:05
> Subject: Re: [Base] Fedora Base Design Working Group (2014-02-21) 
> meeting minutes and logs
> Sent by: devel-bounces at lists.fedoraproject.org
> 
> On Fri, 2014-02-21 at 16:38 -0500, John.Florian at dart.biz wrote:
> 
> > > With the best of intentions, we'd gone from a reluctant exception to 
the
> > > 'no choice' design to a dropdown which included two very different
> > > complex choices: LVM and btrfs. So now the installer path which was
> > > originally supposed to be minimal-choice, very robust and testable 
and
> > > fixable, had become rather a lot more complex.
> > 
> > Everything should be made as simple as possible, but not simpler.
> 
> I don't think that precept applies very well to this area.
> 
> The problem is that there are - and this is probably *literal*, not a
> rhetorical flourish - millions of Special Little Use Cases like yours
> (the one below, snipped for brevity) out there. *You* want it to be easy
> to skip /home. *She* wants it to be easy to resize a Slackware install.
> *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very,
> very clear that we just cannot undertake to support them all and
> guarantee that they are all going to work in a release. It's just _too
> much work_. Everyone agrees that it would be nice if we could, but then
> everyone agrees that it'd be nice if I had a solid gold toilet.

Brr... no thanks.  Well okay, I'd take one for the monetary value.  :-)

> Some
> nice things just don't happen. We do not have the resources to be in the
> business of writing the world's biggest disk configuration tool and
> guaranteeing that it'll never go wrong, which isn't *quite* what we're
> currently trying to do, but it's not far from it.
> 
> It's worth trying some other installers out, just to reset your
> expectations. Have you seen the level of flexibility you get from
> Ubuntu's interactive installer? Windows'? OS X's?

Thank God no.  I last touched Ubuntu about 7 years ago.  The early days of 
FC were so not the RHL (e.g. 7.3) that I'd loved so much.  But then Ubuntu 
left me lacking in community.  I filed so many bugs that never received a 
single response.  The last time I installed Windows it required something 
like 20 1.4MB floppies (and that was probably the best part of the whole 
experience).  I've only *used* a Mac twice, once with the originals back 
in the 80s(?) and again in the 90s -- I've never installed any Apple OS. 
Too damned different for this old dog.
 
> >   I 
> > appreciate your QA angle here.  Every condition in a code path leads 
to 
> > exponential growth in testing.
> 
> And development. This isn't just a QA problem. We do not have the
> development resources to commit to all this stuff working reliably every
> six months.

Here's where you lost me.  Yes, anaconda is going through a rewrite, but 
shouldn't all development be incremental improvement.  You make it sound 
like it has to be gutted and redone every release.

IMHO, nothing kills corner cases like polymorphism.  Remove the conditions 
and you remove the dark corners where bugs like to hide.

> 
> >   However, when I have my admin hat on, I 
> > want flexibility.  I love LVM for that reason.  However, if I'm 
setting up 
> > simple VMs whose backend storage resides in a LV, I have no need or 
desire 
> > for LVM within the VM.
> 
> Does it hurt you to get it, though?

Only in the sense you snipped out: resizing w/o LVM is much simpler when 
disk is virtual, there's just fewer steps.  As I stated though, on the 
host I want/need LVM because in the physical world, LVM makes life way 
more easier.  Yeah, I can live with it in all cases, but then I'm just as 
likely to do a complete reinstall of the VM as to resize the undersized 
file system.  However, that's only practical because puppet is doing all 
the dirty work.

Really my whole problem is MY problem though.  I just have committed to 
the time of completely automating kickstart script generation and 
application.  The GUI installer has been kind enough to me that I always 
seem to have higher priorities (like keeping all my services running atop 
the latest Fedora).


--
John Florian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140224/de89fde6/attachment.html>


More information about the server mailing list