New lockscreen

Aaron J. Seigo aseigo at
Thu Jan 10 20:57:30 GMT 2013

On Thursday, January 10, 2013 19:37:57 Martin Sandsmark wrote:
> So, who is supposed maintain this new screenlocker? In its current state it
> Another alternative is to revert the replacement for KDE 4.10, and instead

disclaimer: i am not the maintainer of this component. i have contributed some 
minor things to its development. however, i'm obviously vested in the 
workspace in general. 

reverting is not going to happen at this point. but what i will do is spend 
tomorrow (and if necessary the next day) going through the various bug reports 
and fixing as many as is possible. none of them look attrociously difficult.

(now, if that's all you care about, you can stop reading right here. if you 
care about directional issues in KDE, read on at your own risk :)

after reading this email, a comment i saw on irc before checking my emails 
suddenly makes sense and i am deeply sadened by it. :/

i will put time in to address the list of bug reports because i care about the 
quality of the release. however, i do so in spite of the email sent. it is now 
the second time this week we've witnessed this approach at "problem 
identification and solution", and certainly more times in the past:

* CC multiple lists rather than send it to the relevant one
* assume the worst and make assertions based on that (e.g. "there are open bug 
reports" == "there is no maintainer")
* put reversion as one of the only (if not the only) semi-realistic option 
offered. starting with a worst case, but probably low effort, solution is a good 
way to simultaneously lower morale ("let's throw your effort out") and feed 
laziness ("we can throw it out, so you don't need to work on it more"). it 
makes us prone to take the worst case solution rather than focus on 
* spend more words on finding someone to accept responsibility ("where's the 
maintainer") than defining problem & solution. iow, we focus on the person 
rather than the product.
* assumptions and conclusions about reactions that have not happened yet ("QML 
== regressions and brokenness").
* do it all at the 11th hour. one might think our development cycle consists 
of a few people working for months on as much as they can and then people 
jumping in at the last minute with Big Massive Problems They Finally Decide To 
Raise(tm). it's almost like we don't have a feature freeze and stabilization 
period that people participate in.

i also have the suspicion that if this was being dealt with in person, it 
would have been said differently. somehow, though, because its an email and 
people aren't actually looking each other in the eye this is what we get. 
second time this week. meh.

besides the brokenness of the approach, i'll let everyone in on what is 
probably not a big secret: for the first time since 4.0, there was essentially 
zero project management in the release cycle for the workspaces codebase. 

this came about after a group of people requested it be that way; despite 
attempts at reasoning it through with them they maintained that position. i'm 
hoping the people involved will realize just how untenable that position is 
now. where i failed with reason, i hope that experience will be an effective 

let's make this *not* the future of KDE development.

Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list