Re: how to make things better(tm)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 4 Mar 2010, Rex Dieter wrote:

> 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. :( )
>

Well, so far all I've heard is that pushing the update was the right thing
to do.  In fact, it was so the right thing to do that I have yet to see
acknolwedgement that had any downsides at all, thus why I used the term
"ignore".

> 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's a question.  I'm just going to throw it out there.  Since, as
with this update, it's impossible to know all of the problems that will
come up when pushing a release out, why not just wait 2 months so everyone
does it when they upgrade to F13?  That way, I have a reason to upgrade to
F13, and F12 doesn't get a reputation for breaking stuff in the middle of
a work week?

None of us know what we don't know, that's why some of us like to be
conservative.  Especially since KDE is currently the main thing I use that
puts bread on my table at night.  I know that's dramatic, but I was late
to a meeting Tuesday because daily updates that would normally have taken
20 minutes or less, took well over an hour because I had things to fix.

The KDE sig has said there's people that only use Fedora because it is
kept super up to date.  What is the KDE sig doing to get the actual
metrics of what people that would prefer a stable release vs the bleeding
edge?

> 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)
>

By "Improve communication" I'd say do an actual study to see what your
users want then publish those results.  The communication side of things
here needs y'all to listen as well not just talk at us.

> 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
>

I'm hoping for this as well, if we're supposed to be tracking upstream as
closely as possible, I'll certainly do it though my preference would be
for more stable releases.  Not knowing is really eating away at me.

	-Mike
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux