A suggestion regarding new features

[Horst H. von Brand]

Dax Kelson <dkelson at gurulabs.com> 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