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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
