New lockscreen

[Martin Sandsmark]

On Thu, Jan 10, 2013 at 09:57:30PM +0100, Aaron J. Seigo wrote:
> reverting is not going to happen at this point.

Fair point, as it now seems to both have maintainers aware of its bugzilla
component and is getting its bugs fixed.

I really like the new screenlocker, both the architecture (one less reason
for me to keep KRunner running), and because I think QML is a good fit for a
screen locker (I've already made a couple of "cute" screen hacks in QML that
I planned on using to replace the XScreensaver hacks), I just didn't want us
to ship something we weren't able to finish in time.


> * CC multiple lists rather than send it to the relevant one

Because I wasn't sure which one was the relevant one. ksmserver is a
kde-core-devel-thing (or so I thought), but plasma-bugs was the default
assignee for bugs (but noone seemed to read them).


> * assume the worst and make assertions based on that (e.g. "there are open bug 
> reports" == "there is no maintainer")

I didn't assume anything. I based my conclusion on several facts.
 * The first one was that there wasn't really any development on it (as I
   said, maybe 5-6 real commits in december, leading up to its first
   release?).
 * The second one was that there was no person as default assignee in
   bugzilla, only the generic plasma-bugs list (which noone seems to follow?
   this is also an issue, though).
 * The third was that I was pretty much told so on IRC.


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

Wait, what? You don't think "I can fix this if I can get some help" is a
realistic option?

The revert was only a suggestion as a last-ditch option in case we couldn't
get it in shape for release.


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

Because it _needs_ a maintainer. That is more important than a short-term
fix-up for release in KDE 4.10 (which I probably could have done myself), and
I think you actually agree with me on that.

Just fixing enough outstanding bugs for it to get released in KDE 4.10, and
then let it rot again is not a good solution at all.

It was not meant as finger pointing, more "we need someone to take care of
this in the long term".


> * assumptions and conclusions about reactions that have not happened yet ("QML 
> == regressions and brokenness").

What do you think people are going to think, then, when we ship something new
with _no_ new features and several very visible (though not necessarily
major) regressions, and noone replying in bug reports?

And it's not an assumption at all, I have seen it happen already in the
various discussions about the pre-releases (see for example the discussion
threads about the releases on reddit.com/r/{linux,kde}. So about making
assumptions:
http://www.youtube.com/watch?v=PivWY9wn5ps


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

Hey, these issues were raised as early as november, and have been steadily
increasing since. I myself didn't notice that none of them were getting fixed
until yesterday, and I wrote this mail as soon as I could.

I don't usually do work on workspace, but I wanted to see if I could fix the
regressions that affected me, and noticed that none of the reported
regressions had gotten any attention at all.


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

Yeah, you'll have to manage with a virtual hug for now: *hug*.


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

I for one did not know, the danger of living in our own little submodule
bubbles, I guess.


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

Agreed.

-- 
Martin Sandsmark
Raiser of the Ruckus