KDE/kdebase/workspace/plasma/applets/tasks (silent)

[Aaron J. Seigo]

On Tuesday 05 February 2008, Sebastian Sauer wrote:
> On Sunday 03 February 2008, you wrote:

ok, this is a veeery long email from me. it's mostly not technical, mostly 
about process and trying to figure out How To Do It Better(tm). it's long 
because i really care about this issue and i'm still finding ways to say 
these things in few words (which is related to "still trying to figure it 
out"). apologies in advance for the immensity ... skip this one if you just 
care about technical issues =)

> It is not a problem if somebody points me at the mistakes I did (and for
> sure I do plenty of them cause I am just a human too) as long as it's done
> in a way that doesn't eat my motivation.

that's fair ball. consider the other side of this:

* free-for-all does have a very negative impact on the code base. we tried 
that, and we moved to peer review because of what that resulted in.

* when asked to do peer review, most people (inc pure volunteers) are totally 
cool with it. a few are really ... not.

now, last week saw many unreviewed commits that actually resulted in rather 
unecessary issues in the code base; this wasn't you alone, just so you don't 
feel like you're being picked on or anything. it's just that people have a 
tendency to fall back to methods that got us kicker and kdesktop (namely: 
really useful programs that did a ton of a stuff but were at a point where 
they hit a brick wall as far as being able to take them further). this isn't 
unique to plasma: i see similar issues with kdepim.

so the problems i'm left with are:

1. how do we ballance keeping the code base functioning with keeping a happy 
community of hackers. how much can we trade off the former for the latter? 
what to do when someone says, "no, i will not adopt your project's 
workflow."?

2. how to keep development as friction-free as possible: it should be fast and 
easy to work on the code base so we can keep a fun, enjoyable and fast pace. 
again, this needs to be ballanced with the "healthy code base".

it's not an easy ballancing act for me, to be honest, and i'm looking for 
feedback and input. on saturday we'll be discussing whether to keep 
review-board or not, for instance. is it helping or hindering development? is 
it useful or just a pain? etc...

i'd also *love* to have an effective way of saying, "working on plasma means 
working with the rest of us." that doesn't piss people off. or maybe it's 
just not possible because some people don't want to work in a team, which is 
obvoiusly one valid way of writing code.

oh, and btw, i do a lot more than my necessary hours even now and i also 
haven't forgotten my years as a code slave by day, freedom hacker by 
weekend ;)

> Else I'll just to anything to block that negativ energy. 

is there a way you can wave a red flag to say, "this is hurting my motivation" 
that doesn't include, "no, i won't do it that way. it's my way or i leave."? 
because dealing with those sorts of reactions really hurts other people's 
motivation (and not just mine, btw)

> > the request here is pretty simple: cooperate with the rest of the plasma
> > developers working on the code instead of committing randomly. it's
> > really not hard to do and actually lets us work faster and better.
>
> I am all for cooperation and I do understand that ppl like to review
> commits.

well, "like" is a strong word ;) but it's good to know you feel this way.

> What I tried to outline (maybe not clear enough) is, that I don't 
> believe that it's a good idea to prevent commits. 

i understand that; that's the whole "development friction due to process to 
ensure quality" thing. it also sucks that every so often i'm out of the 
country. i've actually pulled back on my travel in part to be able to avoid 
that, btw. more ballancing acts =) it was highly discouraging that i should 
be in intermittent contact for a week and have so much go sidewise during 
that time. there was a lot of *good* stuff committed too. that's really the 
challenge, right: how to filter in the good stuff, and weed out the couple of 
not good things. 

remember as well that every step backwards that gets taken usually ends up on 
my plate to make up for. few others who are doing this as a sideline hobby 
are willing to do that. this is the same thing as with kicker, right? back 
then (and i was still a volunteer, so this isn't related to me getting paid 
to do it) i took on the job of protecting the quality of an already fragile 
and completely neglected code base. it's what i do, some personality 
flaw/quirk ;) so this isn't a zero sum game: when i don't manage to weed out 
the smaller bad things, i end up spending time i'd rather spend moving things 
forward working on keeping the house in order.

> Please understand that 
> this is a _plain_ technical issue since subversion just does not allow such
> workflows without sucking the one (those who commits) or the other (those
> who likes to review).

realize that this was also an issue of just plain ignoring the stated design 
goals. it wasn't even a "oops, that patch was buggy" this was "that commit 
goes against the design principles" combined with "someone else already had 
done this work, but apparently this wasn't communicated clearly to everyone 
else and so people duplicated efforts." 

so it's not just a plain technical issue, it's also one of communication and 
cooperation. we can improve on that.

> This is one, if not the biggest, reason why git is 
> such a useful thing since it's designed to address that by allowing the
> committer to just commit and the reviewer to decide if the commit is ok and
> then merge it to "trunk".

i completely agree. this is also why many people are using git locally with 
the git2svn stuff only to push changes upstream. that's still a band-aid 
solution, but better than using trunk as a personal commit log, right? =) 
long run, i want to see kde move to git as well. there are other reasons, but 
this is a big one among them.

> That's why I wrote the longer second reply to Chani to explain my reason
> just after I realized that my previous reply did sound a bit strange.

thanks for doing that =)

> > obviously, whatever you decide to do with your time is your decision.
> > it'd just be nice if the alternative to "i want to work without
> > communicating" was not "i'm going away". i hope you eventually reconsider
> > your reaction.
>
> ok, I did (reconsider), 

yes, when i saw your commit earlier today i smiled and sighed a bit of relief. 
it does pain me whenever someone isn't happy. again, another one of my stupid 
personality flaws. =)

> but I guess we still don't have a working solution 
> for the problem.

but we can find one. or at least, find less-bad solutions, right? ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080205/eefb863b/attachment.pgp