Aaron J. Seigo
aseigo at kde.org
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel