Dax Kelson <dkelson@xxxxxxxxxxxx> wrote: > Progress is great, new shiny frobnicators are wonderful. What many > people (myself included) object to is when old behaviors and > compatibility is broken NEEDLESSLY. Let's have our cake and eat it too! To make omelette, you have to break some eggs... > When implementing new features what about using a decision tree that > looks like the following: > > ====================================================== > > Step 1. Does $NEWFEATURE implementation change old behaviors or break > compatibility? > > a) NO -> Great go for it! Let's all eat cake! > b) YES -> See step 2 It is not really new, then. > Step 2. Can $NEWFEATURE be implemented so that it doesn't change old > behaviors or break compatibility? > > a) NO -> Uh oh, see step 3. > b) YES preserve both -> Excellent. Let's all eat cake! > c) YES preserve compatibility -> Great no "exceptions". Let's all eat > cake! > Examples of "2c" include GRUB, Completely different from lilo. Check. > udev/hal, Still trying to wrap my brain around that. Check. > ALSA, Massive breakage, much gnashing of teeth, extensive flamewars. Check. > hda -> sda, Even more massive breakage, gnashing of teeth, extensive flamewars. Check. > LVM, There are still people around claiming it breaks their setups so badly they go to heroic ends to avoid it. Check. > FACLS > on /dev files, Had my own run ins with this, wan't really nice. Check. > CUPS, Was a real mess until it got sorted out. Now it is great (if still a bit misterious to me). Check. > POSIX CAPs to replace SUID, Massive change in sysadmining. Check. > etc. All distros moved > these features in relative unison so I can toss that old knowledge out > of my brain (and documentation). Old documentation has a penchant for hinding in all sorts of nooks and crannies of the 'net, and comes to light only when $RELATIVE_NEWBIE looks around for a fix for $MISTERY. > Step 3. Does the benefit of $NEWFEATURE outweigh the cost of changing > the old behavior or breaking compatibility? Obviously this can be > subjective. > > a) NO -> Good effort. Have you considered picking one of the other many > areas in Linux that need improving and working on that? > b) YES -> OK, $NEWFEATURE must be really awesome. Please double check > that you can't resolve this in Step 2. So Step 2 is a no go? OK, let's > do it. > > ====================================================== > > Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST > PLACE. Not even your own "step 2" examples qualify... not by a long shot. The pain is forgotten by now, that is all. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
