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 improvement. * 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 teacher. let's make this *not* the future of KDE development. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel