how to make things better(tm)

Rex Dieter rdieter at math.unl.edu
Thu Mar 4 16:20:41 UTC 2010


Mike McGrath wrote:

> Alternatively, the KDE SIG could stop ignoring the problems that were
> caused this week by the updates they released.  Even an "I'm sorry I broke
> your desktop" would go a long way.  The update the busted my desktop
> happened on a pretty vanilla install, I suspect lots of users experienced
> issues.

To be clear, no one is ignoring anything.  (What a silly thing to say?... 
well, maybe not so silly... means there's a bad pr/perception problem. :( )

Like most any group making hard decisions, the KDE SIG bases them on the 
best information available.  Fact is, we extensively tested this new version 
for over a month, and every serious issue/blocker that was reported or 
identified was addressed prior to releasing this. 

Unfortunately, it seems there were more problems than what we were aware of 
when the decision was made to do the 4.4.0 (stable) update.  Yeah, that 
sucks.

So here we are in a bit of a pickle, with many unhappy folks.  Brain dump on 
"how to make things better(tm)" (or for you glass half-empty folks, "how to 
make things suck less(tm)"):

1.  Improve communication.  Seems there's a bit of disconnected between kde 
sig plans/intentions and the expectations of some significant portion of 
other fedora contributors and user-base.  Also, continue to work toward 
making constructive feedback the obvious and expected norm.  Clearly define 
what this is, and it's intrinsic high value.  imo, folks like to know that 
they are being heard, and to feel that their constructive participation 
yields positive results.

(dunno about everyone else, but this, to me, seems to be the biggest 
"problem" at hand)

2.  better and more testing.  Work more to tap into ongoing fedora 
qa/testing efforts.

3.  adjust plans/policy wrt kde upgrades.
 a. implement kde stability proposal as is (to limit 4.x type upgrades to at 
most one per fedora release)

 b. simply do new 4.x versions only for fn+1?  pros: less chance to disrupt 
current installations.  cons:  pushes off the problems to users upgrading to 
fn+1.

 c.  defer any sig decisions, wait for fedora-wide fesco policy/guideline

....

99. profit.


-- Rex



More information about the devel mailing list