how to make things better(tm)
 

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

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

how to make things better(tm)
 

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to make things better(tm)
 

On Thu, Mar 4, 2010 at 16:20, Rex Dieter <rdieter@math.unl.edu> 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. :( )
>
> 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.

Yes there is the odd regression and i have been bitten by the odd one
over time myself but in the vast majority of cases i have had no
regressions at all by the time the updates hit stable. If i wanted an
absolutely rock solid distribution and desktop there are plenty of
other choices out there but i have personally found the improvements
with each update to far out weigh the very occasional regressions and
bugs (that mostly includes the betas and rcs from kde-redhat too).
Keep up the great work.

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

A simple way to encourage constructive input from users on both the
state of play and providing more bug reports might be to regularly
(perhaps even daily as soon as a significant update comes along) to
post a list of all the bugs that are reported against the updates
(both blockers and not). That might encourage people to report bugs,
give people an idea of what kind of problems to expect during testing,
feedback from users about what they consider blockers and what not,
give users an idea about how close things are to being released. All
of this information would then be useful for during the meetings to
decide if the updates really are ready in the eyes of the end users.

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

That can never hurt although i would say the testing provided by users
of kde-redhat already provides more useful feedback than the qa team
probably has the resources for.

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

If you do one update like that per release than you may as well do the rest.

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

I generally keep up to date with the latest release but i would say a
better balance might be just to implement everything in the next
release and kde-redhat as is currently done. Then in the latest
release and just perhaps leave the updates for the most stable release
in testing just a bit longer to make extra sure regressions are fixed
as best as possible.

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

In my opinion most of fesco has lost it's mind even contemplating the
recent suggestions. Please don't destroy one of Fedora's greatest
strengths for the sake of some morons who want Fedora to be RedHat
with a different colored hat... I am getting fed up of Fedora's latest
identity crisis and if the KDE SIG just turns into a sheep then that
would be the last straw for me.

> ....
>
> 99. profit.
>
>
> -- Rex
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to make things better(tm)
 

On 03/04/2010 11:28 PM, John5342 wrote:
>
> In my opinion most of fesco has lost it's mind even contemplating the
> recent suggestions. Please don't destroy one of Fedora's greatest
> strengths for the sake of some morons who want Fedora to be RedHat
> with a different colored hat... I am getting fed up of Fedora's latest
> identity crisis and if the KDE SIG just turns into a sheep then that
> would be the last straw for me.
>

While it is alright to criticize positions it is not acceptable to
engage in name calling and please refrain from doing so

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to make things better(tm)
 

John5342 wrote:
> A simple way to encourage constructive input from users on both the
> state of play and providing more bug reports might be to regularly
> (perhaps even daily as soon as a significant update comes along) to
> post a list of all the bugs that are reported against the updates
> (both blockers and not). That might encourage people to report bugs,
> give people an idea of what kind of problems to expect during testing,
> feedback from users about what they consider blockers and what not,
> give users an idea about how close things are to being released. All
> of this information would then be useful for during the meetings to
> decide if the updates really are ready in the eyes of the end users.

We're already doing that (for the big updates like 4.4; we found it not
needed for the bugfix-only point releases), it's called a "tracker bug", see
e.g.:
https://bugzilla.redhat.com/show_bug.cgi?id=kde-4.4
https://bugzilla.redhat.com/showdependencytree.cgi?id=533921&hide_resolved=0

> In my opinion most of fesco has lost it's mind even contemplating the
> recent suggestions. Please don't destroy one of Fedora's greatest
> strengths for the sake of some morons who want Fedora to be RedHat
> with a different colored hat... I am getting fed up of Fedora's latest
> identity crisis and if the KDE SIG just turns into a sheep then that
> would be the last straw for me.

Let me be clear: while it is not my intention at all to be a "sheep" and
while I'm strongly opposing that sort of policies, if FESCo were to mandate
that all Fedora updates may only be to bugfix releases (or worse, that new
upstream versions are not allowed in updates at all), KDE SIG would not be
in a position to do something else (in the official Fedora updates; of
course, kde-redhat is a different story and kde-redhat stable might carry
the updates Fedora doesn't want anymore). Ignoring the policy would not be a
workable solution, it could lead to the updates getting rejected or other
sanctions and it'd also confuse users (e.g. "Why is 4.4.0 in the updates,
the policy says such updates are not allowed?"). So the only thing we can do
is to try to prevent such a policy from being passed in the first place.

Kevin Kofler

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

how to make things better(tm)
 

On Thu, Mar 4, 2010 at 19:00, Kevin Kofler <kevin.kofler@chello.at> wrote:
> John5342 wrote:
>> A simple way to encourage constructive input from users on both the
>> state of play and providing more bug reports might be to regularly
>> (perhaps even daily as soon as a significant update comes along) to
>> post a list of all the bugs that are reported against the updates
>> (both blockers and not). That might encourage people to report bugs,
>> give people an idea of what kind of problems to expect during testing,
>> feedback from users about what they consider blockers and what not,
>> give users an idea about how close things are to being released. All
>> of this information would then be useful for during the meetings to
>> decide if the updates really are ready in the eyes of the end users.
>
> We're already doing that (for the big updates like 4.4; we found it not
> needed for the bugfix-only point releases), it's called a "tracker bug", see
> e.g.:
> https://bugzilla.redhat.com/show_bug.cgi?id=kde-4.4
> https://bugzilla.redhat.com/showdependencytree.cgi?id=533921&hide_resolved=0

I was referring primarily to making it more visible on the mailing
lists. Being vocal to the users and testers may well create the same
in return. Obviously the purely testers will be aware of the tracker
bugs (me included). I don't think there is anything wrong with the
current way. Making it more visible by highlighting the list of bugs
to the KDE testers might however draw in a few extra people and
improve the feeling of openness about the updates even more than
already. It was merely an extension of the current ideas as Rex
appeared to be requesting.

>> In my opinion most of fesco has lost it's mind even contemplating the
>> recent suggestions. Please don't destroy one of Fedora's greatest
>> strengths for the sake of some morons who want Fedora to be RedHat
>> with a different colored hat... I am getting fed up of Fedora's latest
>> identity crisis and if the KDE SIG just turns into a sheep then that
>> would be the last straw for me.
>
> Let me be clear: while it is not my intention at all to be a "sheep" and
> while I'm strongly opposing that sort of policies, if FESCo were to mandate
> that all Fedora updates may only be to bugfix releases (or worse, that new
> upstream versions are not allowed in updates at all), KDE SIG would not be
> in a position to do something else (in the official Fedora updates; of
> course, kde-redhat is a different story and kde-redhat stable might carry
> the updates Fedora doesn't want anymore). Ignoring the policy would not be a
> workable solution, it could lead to the updates getting rejected or other
> sanctions and it'd also confuse users (e.g. "Why is 4.4.0 in the updates,
> the policy says such updates are not allowed?"). So the only thing we can do
> is to try to prevent such a policy from being passed in the first place.

Sorry. That was perhaps rather strongly worded. I was not suggesting
going against policies if they are mandated. My complaint about sheep
was towards the option of defering. Not the act of following what is
mandated if such policies are passed. Until such stuff is mandated
(hopefully never) everything should be done the right way. Not what
fesco currently seems to be considering.

What i said about leaving Fedora behind if such policies are passed
though and my views towards those members on fesco who are even
considering these policies do however very much stand and i hope that
such policies are never passed. It would be a real shame for an
otherwise brilliant distribution and a waste of some great KDE
packagers who are currently doing an excellent job. My current views
towards the suggested policies and the fesco members considering such
policies do however probably belong in another thread.

> * * * *Kevin Kofler
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to make things better(tm)
 

On Thu, Mar 4, 2010 at 9:50 PM, Rex Dieter <rdieter@math.unl.edu> wrote:
[...]
> 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.
>

Does that mean if Fedora N is released with KDE 4.x, the users get
4.x+1 only in Fedora N+1? It sounds diagonally opposite to the
latest-and-greatest, bleeding edge policy of Fedora. And yes, a lot of
users will be unhappy if they have to wait 6 months to see the next
KDE SC release in Fedora, /me included.

--
Cheers,
Rajeesh
http://rajeeshknambiar.wordpress.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to make things better(tm)
 

John5342 wrote:
> Sorry. That was perhaps rather strongly worded. I was not suggesting
> going against policies if they are mandated. My complaint about sheep
> was towards the option of defering. Not the act of following what is
> mandated if such policies are passed. Until such stuff is mandated
> (hopefully never) everything should be done the right way. Not what
> fesco currently seems to be considering.

Deferring means continuing with our current policy (always push minor
feature releases, just leave disruptive major releases like KDE 4 (or KDE 4
ports of applications with significant rewriting and some feature
regressions) to new releases, like we did for KDE in Fedora 8 vs. 9, and for
applications as well, except in cases like Konversation where the KDE 4 port
came with no feature regressions and no significant UI changes) unless/until
FESCo mandates anything else. That's quite the opposite of sheepishly
following suggested conservative policies.

Kevin Kofler

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

how to make things better(tm)
 

On 03/05/2010 10:16 AM, Rajeesh K Nambiar wrote:
> Does that mean if Fedora N is released with KDE 4.x, the users get
> 4.x+1 only in Fedora N+1? It sounds diagonally opposite to the
> latest-and-greatest, bleeding edge policy of Fedora.
>

If you would point me to such a "bleeding edge" policy then I could
agree but I believe this is merely assumed by some and if you want the
latest always you could use kde-redhat repo

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to make things better(tm)
 

On Thu, Mar 4, 2010 at 11:20 AM, Rex Dieter wrote:
>
> 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.
>

Maybe 1 month of testing was not enough. We should have left it in
update-testing for 2 months, 3 months... This would give more time to
the "curious" users to test KDE. This is why I defend the extensive
use of updates-testing idea. 4.x.0 releases stay in updates-testing
for a month. It is never pushed to stable. After a month 4.x.1 is
released with bugfixes. That one goes to testing, stays there for
about another month and then it will be pushed to stable. x.0.0
releases wait 1 full Fedora release to get in (speaking of 4.0.0 if
anyone didn't notice.).

There is one more thing. Very important thing. We have been pushing
KDE releases asap so far, and although it hurt me at times (at school
and at work), I like it. I don't blame people who don't. Here is the
thing: The bugs need to be reported most of the time to get fixed.
Fedora has been a pioneer in KDE development in this sense. If we
don't push 4.x.0 releases to stable, the 4.x.1 will be more buggy,
since not many distros do kde 4.x.0 updates to their stable releases.
Someone has to make some sort of sacrifice but I cannot come up with a
good-for-all resolution for this issue.

Orcan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel