On Wed, 2008-10-29 at 13:31 -0400, seth vidal wrote: > On Wed, 2008-10-29 at 11:15 -0600, Dax Kelson wrote: > > > Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST > > PLACE. > > > > Many people have voiced concerns that to many $NEWFEATURES are going > > straight to Step 3 without exploring a Step 1 or Step 2 resolution. > > > > No sane person would prefer a Step 3 resolution versus a Step 2 > > resolution. > > I disagree with this last statement. Many sane people would prefer going > straight to step3. Mainly b/c it is easier. think about it - if you > don't have to lug around years of legacy it is much less work. > > It's the difference b/t fixing something old and buying a new one. > > Step 3 is a consumable society solution. > Steps 1 and 2 are about keeping older systems working while slowly > migrating to newer solutions. > > Step 3 is an artifact of a generation (of which I am one) raised to > believe it is better to buy a new one than to fix the old one. But it is > not insane, let's be clear, it is very sane in that it is the path of > least resistance in terms of maintenance. The problems is it is not > sustainable when you're trying to make things work for a user/developer > community that is as diverse as ours is. You are right. To clarify, it is based on your role/perspective. Going straight to step 3 is sane from the perspective of the developer saving time. However, there are many circumstances where doing a Step 1 or Step 2 is NOT a herculean carry-atlas-on-your-shoulders effort. Often it is very minor. The developer time is spent once, the user/sys admin time is spent over and over again. I'm not sure you are arguing to always go Step 3, but if you are, not all developers agree with you. Apparently some care about user/sys admin time. Consider the adoption of rsyslog (a Step 2 solution) over syslog-ng (Step 3). I would prefer if the shepherds of my distribution of choice didn't treat it as a consumable. There are costs to incompatibility and needless churn that may not be obvious on first glance. Dax Kelson Guru Labs -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
