New lockscreen

[Aaron J. Seigo]

On Friday, January 11, 2013 10:01:58 Martin Sandsmark wrote:
> 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.

as long as we keep in mind that ends do not justify means. this was NOT the 
way to affect this result.

there are better ways of accomplishing the intended result, and we should 
practice them. that's all i'm trying to get across here.

> screen locker (I've already made a couple of "cute" screen hacks in QML
> that I planned on using to replace the XScreensaver hacks), 

this was our thinking as well: people who really want screen savers will 
implement cute things in QML. they will not require hacks to integrate with 
the workspace as the old X screen saver do, they can include actual 
functionality (e.g. sleep, shutdown; in 4.11 likely a switch user UI) and user 
interaction. with QML2, we'll have access to openGL shaders for extra fancy, 
etc.

> I just didn't
> want us to ship something we weren't able to finish in time.

this feature had been sitting around for over a year. it would easily have sat 
for another year or more. the workspaces would continue to remain in limbo. 
how long should we wait until something is ready to be shipped? why do we end 
up waiting so long in the firs tplace? why do we suggest "revert" rather than 
do the work to figure out how to fix things?

i don't expect you (or me :) to answer those questions right now, right here. 
i do expect us to tackle them at some point, however, rather than call after 
call for revert, etc. we instead need to be figuring out how to improve the 
underlying issues, and not with a few days until release. 

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

you guessed correctly by sending it to plasma-devel. if it wasn't the right 
place, someone would have pointed you elsewhere. cross posting is not 
something to because one is unsure; this ought to be common sense, but it 
seems many have forgotten. 

as for ksmserver: it is in kde-workspace, that makes it a workspace thing. 
"kde platform*, plasma workspaces and applications" is not a marketing game.

* platform becomes frameworks in 5.0

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

actually, it isn't the first release of this locker. it's been released a 
couple times already, just not as part of kde-workspace.

there are also components in kde-workspace that get zero commits per release 
(usually because they are "done"). this one got 5 last month. that's not dead.

>  * The second one was that there was no person as default assignee in
>    bugzilla, only the generic plasma-bugs list

this is how most of the workspace components are done so that we don't end up 
with a bus factor of 1 on components.

>    (which noone seems to follow?

indeed, for a few months it has not been tended to. as i noted in my prior 
email, there was no project management applied to workspaces for 4.10 and that 
led to a number of bad consequences, this being one of them. in the past, this 
was not the case. you may have read many blog posts in the past about our 
activity with the bug reports (in the 1000s). 

in any case, you've used one metric and drew a conclusion about project 
activity. asking instead of concluding would have been nicer and gotten a 
quick, accurate answer.

it turns out that "bugs list is not being managed" did not mean that the 
screenlocker had no one who working on it or caring about it.

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

not really, given the context of the email as you wrote it:

"no maintainer, and the new thing is useless": 8 lines
"link to bug list": 2 lines
"i could help if someone (who isn't there right now?) helps me": 2 lines 
"revert": 4 lines

the email did not communicate "let's figure out how to get this to where it 
needs to be". 

i don't get why anyone should have to filter out 13 lines from a 16 line email 
to get to the 3 lines that matter. if the point was "this needs fixing, i'm 
ready to help" why not just write that? why not ask questions that focus on 
solution?

when it is observed that 3/4ths of the communication was worse than not 
necessary, the justification is the 1/4th that might have been helpful. why 
don't we just skip the 3/4ths, or at least reduce it to where it is not the 
majority of our communication?

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

it was the main option offered in the first email sent. that's not "last-ditch" 
by any definition.

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

it needs people working on it. one of those people may be a maintainer, but 
they also might not be. right now, hunting for the maintainer is secondary to 
fixing it. once fixed up ("mission accomplished"), then we can step back and 
figure out who is maintaining it. if we can't fix it up, then we ask for someone 
to justify its inclusion.

i mean, are you ok with me fixing things even if we don't have an identified 
maintainer right now? or would you rather me not fix things until someone 
raises their hand and says "i'll be the maintainer?"

this is a question about our priorities, and our ability to deal with short 
term needs as well as long term planning without them interfering with each 
other.

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

i don't agree, actually. given that we'd like to make a 4.10 release, and that 
a reversion is not on the table as an option, getting it fixed up for 4.10 is 
the most important thing right now. everything else is secondary right now.

once we've dealt with the immediate issue, then we can look at the long term 
issues.

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

now you're talking about 4.11 and beyond.

if our concern was 4.11 and not 4.10, reverting wouldn't even come up. we'd 
ship it as is (because it doesn't matter) and focus on 4.11. obviously, since 
we're considering what to do about 4.10 and that we're into RC3 already, our 
priority concern is 4.10. after that's sorted, we can figure out what to do in 
terms of maintainence.
 
> It was not meant as finger pointing, more "we need someone to take care of
> this in the long term".

you did not write about the long term in your original email. perhaps you were 
thinking about it when you wrote it, but it wasn't in the email. the closest 
was "postpone it for 4.11".

the literal message of the email was: "it seems nobody maintains this, lots of 
regressions, it doesn't do anything useful anyways, i could help if i knew 
how, maybe we should revert it instead"

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

instead of projecting the sky will fall, we could spend our time fixing the sky 
so it doesn't fall. 

sometimes we get so caught up freaking out about a future that has not 
happened yet that we don't do anything now to prevent it.

> 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

a "clever" link to a michael jackson song. would you be fine if i did the same 
to you? or would you consider it juvenile, cheeky and disprespectful?

better yet, let's skip to the part where we start changing these communication 
patterns in KDE because they suck and we are better than that.

> > * 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'm refering to the precise sort of email sent about this (and other issues in 
4.10), not individual bug reports.

the idea that "nobody noticed until now" means something is rather broken in 
the development process. it should never have to come to the 11th hour; it 
ought to be dealt with rather earlier.

this is not the only dev cycle where big, new and potentially disruptive 
changes have gone in. they happen nearly every cycle, in fact. they haven't 
caused such massive, unmanaged issues in every cycle in the past because 
someone had been doing project management and there was a team of people 
working in support of that. 

direction and commitments were developed and applied *during* the cycle, not 
in the last week before release. and that's what i was getting at when noting 
that 11th hour panics are not the answer.

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

:)
 
-- 
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: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130111/5811e33d/attachment.sig>
-------------- next part --------------
_______________________________________________
Plasma-devel mailing list
Plasma-devel at kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel