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