Dax Kelson 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!
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
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, udev/hal, ALSA, hda -> sda, LVM, FACLS
on /dev files, CUPS, POSIX CAPs to replace SUID, etc. All distros moved
these features in relative unison so I can toss that old knowledge out
of my brain (and documentation).
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.
======================================================
I reject your step 3, and substitute my own:
3) If you'd never seen linux before and knew nothing about it, and you
were shown both the old and potential new behavior, how would the old
behavior appear?
a) It'd be better -> Time to rethink things.
b) It'd be about the same -> Go to 4
c) It'd be worse -> Probably worth pushing for, but get a lot of
opinions. You've been wrong before.
d) In the face of the new solution, it'd appear wrong/broken -> Do it.
4) Is this change really that significant?
a) Yes -> same as 3c
b) No -> Do it.
--CJD
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
