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

[Aaron J. Seigo]

On Tuesday 05 February 2008, you wrote:
> On Tuesday 05 February 2008, Aaron J. Seigo wrote:
> > * 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.
>
> It also has positive advantages like quit a lot of commits, like feeling of
> beeing an important part within the process and like working together with
> everybody else on the same codebase in real-time.

agreed.

> My reply from Feb, 01 where I answered to the question "did you get this
> stuff reviewed before committing?" with "you can review it now." wasn't
> meaned to be sarcastic but just how I worked in KDE last 5 years. That
> means, first commit and then review (your own commits and the commits of
> others) and imho it was working quit well that way through I agree it's far
> away from beeing optimal.

it just doesn't work well with libplasma and some of the key applets. why? 
because:

* it's not the same as what we've done before, so there's a lot of new 
concepts to ensure don't get violated. the KConfig::sync() call in 
DefaultDesktop that made it into 4.0 is a good example of that.

* most of the people working on this stuff haven't worked on workspace issues 
much before, if at all. there are a lot of details ... e.g. right now the 
pager also moves a window's geometry when it moves between desktops; this 
isn't always the correct thing to do (e.g. maximized windows, when the pager 
areas are too small for accurate placement) ... 

unfortunately, i'm far more efficient at reading patches before they go in 
rather than after. in particular, that's because i have to wade through the 
patches and decide "does this one need review? yes? no?" and if the commit 
covered a lot of code the diff isn't provided.

i was both spending way too much time in my day fixing other people's commits 
and missing way too many accidents due to the above. that's the reason for 
asking for peer review. and since then, development hasn't slowed down (quite 
the opposite) and my time is much more free to work on new features and bug 
fixes others aren't working on.

> > 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."?
>
> I would say, that to push workflows on developers is a mistake. This should
> be done on a tech-level without changing the way developers work.

that's a good theory, but right now reality doesn't allow for it =/

> Joel once wrote a nice blog-entry about what he described with "beeing in
> the zone". That is this time a developer got really productive and pushes
> code out in an incredible speed. It is imho very important to don't block

absolutely; and i can think of several ways to work with this:

a) use git locally (as i mentioned before, several people are doing this 
already)

b) find someone to peer review critical changes as you make them. i'm often 
peer reviewing "live" on irc. did it today a few times in fact.

there are ways to get what you need here without dumping bugs into trunk. 
that's the goal to work towards.

> > 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".
>
> ++
> through I guess the kernel-devels didn't solved this 100% too yet ;)

yeah; dunno if anyone has. =) i'd be happy with 70% though ;)
 
> > 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...
>
> oh, it can be a quit useful thing. E.g. myself would land his work to turn
> the "configure desktop" dialog into a kcm there (nah, far away from beeing
> ready or usuable yet) since it just touches lot of code and review would be
> more then welcome there.

this is something we should discuss before you start coding on it as there are 
probably some non-obvious issues to take into consideration. in particular, 
the DefaultDesktop can be replaced by any other Containment. which means that 
the eventual "desktop background" kcm needs to handle containments and get 
configs from there. i've discussed this before with some of the people 
working on the desktop wallpaper stuff, but if someone is going to work on 
the Next Step of this, i probably need to sit down and write out some of the 
design issues that need to be taken into consideration.

> It's just the case that a "each commit needs to go through a webbased board
> and you have to wait some time till somebody says ok" solution just is
> overhead++ imho.

that's never been the goal. things in your own engines/applets keep going the 
way they always have; if you can get peer review elsewhere, great; if the fix 
is obvious or it's a trivial add, go for it.

this is all about non-trivial changes to core elements.

and even then, there have been times when people have worked on a given thing 
straight into svn (the wallpapers being an example there), though often 
working with someone else as well to bounch ideas off of.

what's really not great is working on a feature set to a core element 
(libplasma, the default containments, etc) without even giving anyone a heads 
up that it is being worked on. at the very least it raises the possibility of 
duplicated effort. i'm not sure how i would've felt had i been Ruphy and all 
my work (which i remember him talking about, either in his blog or on irc; a 
message to the mailing list would've been best, really) voided in one 
surprise commit.

review-board, however, is there to make sure that patches that were ending up 
on the list don't get lost on the list. that was starting to happen due to 
how many were getting posted .. that's great since it was a problem of 
success (many people working on many different things) but needed a solution. 
review-board might be such a thing.

> > 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.
>
> heh. Maybe we define teamwork and review different here. But if I look at
> the commit somebody else did land, it's a review. If I extend the code
> somebody else wrote, it's teamwork.
> To try to do all this in parallel is imho just not possible cause we are
> still developers from all over the world and just don't work at the same
> time at the same piece of code.

agreed; but again, the idea is to work in a way that doesn't result in things 
that don't belong in trunk going into trunk.

> same in nicer words and maybe even more explicit with a concret sample.

actually, that was exactly how you were communicated to originally. you 
decided that you'd justify your commits instead.

moreovier, i (and others) have been doing this for months on panel-devel and 
irc. forgive me if every once in a while i express myself when someone is not 
being cooperative. i am only human and i do tire of being repetitively nice, 
especially when being nice is returned with "you're wrong, i'm right, yeah i 
know this your project too but whatever..." which is exactly what i got from 
your replies.

> Unfortunately with the wordings above the result is the opposite of what
> you tried to achieve there and for sure that didn't provide you a good
> feeling too :-(

you're right, i was pissed off when i wrote that. mostly because you'd been 
asked nicely and decided you knew better anyways.

> > that's really the challenge, right: how to filter in the good stuff, and
> > weed out the couple of not good things.
>
> guess thereis just no way to be really sure that no regressions or new bugs
> will land. But as long as ppl to review and fix that bugs again and as long
> as the frequency new bugs land is lower then the frequency bugs got
> fixed... ;)

that's the problem here: bugs land quicker than i can fix them without 
reviewing these kinds of fixes. worse yet, code lands that ends up being very 
difficult to work with. i have, at times, just simply had to rewrite stuff 
which is a waste of everyone's time when it could've been improved very 
easily much earlier on.

> but, yes. It's a problem without proper solution :-/

it doesn't need to be 100%.

> > 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.
>
> and I am pretty sure you also learned over the time just like me did and
> the quality of your commits just increased over the time. Probably also by
> doing mistakes and by being teached by someone how to do it better. I guess
> that's a very important process and something FOSS pays back to there
> developers. Those experiences are just in no way affordable and one of the
> reasons why FOSS-developers are the better developers :)

absolutely. we also need to find a way to do the learning without screwing up 
libplasma, plasma itself or some of the core desktop components.

> > > 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."
>
> Guess I still don't got that point about "design principles". Is it those
> GUI-dialog? Well, that was really only 5% of the work (in terms of time
> that was needed till it was working).

the GUI dialog is one thing. the actual settings (tiny, small ..) are another 
as it doesn't translate well to a non-dialog approach, 
introduces "interesting" behaviour like when you set it to custom but the 
same size as one of the presets, etc ...

moreover, as soon as we get something like this in svn, it has a way of 
replicating throughout the code base to other places as people take it as a 
cue that "this way is just fine". 

> works somehow is in. Somebody will extend it later anyway just like I
> extend the work others did.

it isn't that easy. let's say that this configuration style is put into 4.1 
and people start saving their config files with it. now we have to support it 
from the point out. and if that happens to make approaching our goals with 
plasma (which are not, btw, "recreate kicker's feature set") then what? yeah, 
we're screwed. that's why these things are slightly important.

i understand you just want to set the size of your panel. i have no issue with 
that. but if scratching that itch and throwing the result into svn means 
jeopardizing the long term goals here, what do you think?

> > 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. =)
>
> I was btw also pissed I saw that somebody else did broke it and my first
> intention was to just revert the whole commit. But I got over that initial
> feeling and then just tried to fix it + provide feedback why it is wrong.

indeed. this is, however, a very different kind of problem than what we're 
dealing with. we're talking about rather major changes to *how things work* 
not replacing one class name with another.

it's not about perfection in every commit, it's about trying to make sure that 
plasma has a future in spite of everyone's good intentions.

as a simple example, how often do you think about plasma's use:

a) in other apps
b) in a media center presentation
c) on devices without mice
d) on small devices like the eee pc

or how plasma will be used by different user segments?

these are the sorts of things i sort of *have* to think about on a fairly 
regular basis. yeah, makes my life a little more annoying ;) and it would be 
awesome if we can all find a way to make it work out so that while i'm also 
worrying about these things that you probably don't need to really care about 
that your efforts don't result in negative side effects.

-- 
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/da5c10ed/attachment.pgp