Rant: So you want help?
thomas.friedrichsmeier at ruhr-uni-bochum.de
Mon Nov 8 12:27:02 CET 2010
On Friday 05 November 2010, Ralf Habacker wrote:
> Am 5.11.2010 16:27, schrieb Thomas Friedrichsmeier:
> >> The compiler discussion is old already, and it won't be solved any time
> >> soon. So let's try to focus on the other problems first.
> > Yeah, I know, I'm late to the party. But BTW, if I'm not mistaken this is
> > another example of a discussion that should have been had on the list,
> > instead of behind the scenes.
> strong words -
> http://dot.kde.org/2007/09/18/windows-developers-meet-berlin was the
> place where this has been discussed - i did not see you there.
Well, to elaborate a bit, I'll break this up into three sub-issues:
1) The timing. I wasn't even remotely connected to the KDE on Windows project
at that time. No matter how and where you would have discussed this, you would
not have seen me there. I *know* I am late to the party. And I can hardly
complain that you reached a decision at that time, and neither about which
decision you reached, or why. I'm not trying to turn back time.
2) The "place" of discussion. Perhaps *at that time* the meeting in berlin
really was a good place to decide on this. Perhaps it really allowed all
relevant people to be there, or at least to feel represented, there. I can't
comment on that. But I'll use strong wording again: In general, and for any
community project, I find it presumptious to think that a physical meeting is a
good place to reach a final decision on a core aspect like this (and one that
was not entirely uncontroversial, as far as I understand). Core strategical
decisions may well be *discussed*, and *prepared* on a phyiscal meeting. A
face-to-face meeting has obvious advantages for discussion. But attending a
physical meeting means a large investment of time (and for most: money), and
for hobbyists with limited time, and those living far away, it is quite likely
to be a prohibitively large investment.
So if you want to allow these people to participate in decisions, then make
sure the final words on core decisions are spoken in a forum that everybody has
a real chance to participate in. The mailing list looks like an obvious
Now, democracy is not the be all and end all in software development. For free
software, in particular, "the ones who do the work are the ones to decide" is
still a golden rule. Just keep in mind that clinging to this a little too
closely can easily end up in "the ones who decide are the only ones left
willing to do the work".
Again, I am not trying to turn back the time. The decison has been made, and
perhaps *at that time* a physical meeting was an appropriate forum for that.
But if you care about community partcipation, then please keep in mind that
physical meetings (or IRC) may not always be the ideal forum for everything.
3) Documenting the decision. If it's a core strategical decision, and esp. if
it keeps being brought up, then, by all means, make sure to document it
properly and visibly.
I knew that the question of supporting multiple compilers in emerge was a non-
negotiable issue - because I happen to have touched on that spike, earlier.
And so I did not bring this up, again.
I expected that the suggestion to release binaries for only one compiler would
be controversial. I did *not* know, or even expect that opinions are similarly
strong, and that the discussion is similarly dead on this topic.
Well, eventually, I have been told. So I have attempted to document this at
. Please take a look to make sure you are ok with the way I've tried to
And so, whenever the next fool brings up this issue, and *as soon as* the next
fool brings up the issue, you can point them to this FAQ, and save everybody
involved a whole lot of time and frustration. This fool, here, would have
appreciated being told about it on or around October, 12, for instance.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20101108/51e06a10/attachment.sig
More information about the Kde-windows