Modules and Maintainers
mueller at kde.org
Thu Dec 20 17:16:17 CET 2007
On Wednesday 12 December 2007, Allen Winter wrote:
> For 4.x, where x >=1, I think we need to require maintainers for all our
Can you clarify why this is a good idea and why we must require it?
> And, I think we need to consider consolidating some modules out of
> existence. We might consider merging kdeutils, kdeaccessibility and kdetoys
> for example back into the larger modules or into extragear.
What would be the advantage of it? Why do you want to do it? What would be the
kdetoys has for historic reasons stayed small because it was a good testground
for buildsystem changes. I also don't think that mixing kdeutils and
kdeaccessibility is a good idea. Keeping Accessibility separate has
advantages, and it is what users expect (I think).
I don't believe that "putting it all into extragear" will solve anything.
extragear just means that somebody else has to do the release planning. It
doesn't make our job of planning the KDE release any simpler or faster to
Also, the actually difficult modules like kdeadmin or pim/network are not
mentioned in your proposal. Why is that so?
> If we had a kdesdk maintainer this person would have been more aware
> of the kompare issue and hopefully would have handled it better than I.
What was not handled? In the end it counts that it was handled ;) However, for
release coordination purposes, it is more important to communicate the
details of the problem first, together with the proposed solution and why and
This is not the case at the moment: Instead, most people make a suggestion
like "I think we should do XX. if nobody objects until YY, I'll do so". This
is fine for coordination - nobody else will interfer. but it doesn't solve
communication. Nobody knows if the reason why a certain change was necessary
was justified, because no reasons were given. Without proper information,
nobody can suggest an alternative route that might make the whole job easier.
Instead, many people have either no opinion to voice, or feel stupid by
asking about the details, or are of noisy nature and ask anyway. Which causes
a long, stormy mail communication where in the end noone knows anymore what
was decided, or if anything was decided at all.
I believe this is something where we need to improve on much more than having
a rule like "we need to tag a name to each module", because then everybody
has n persons to talk to for each change. This does not improve release
coordination. It does improve the situation in case there is a concrete
problem with one particular module, because I know about an expert at hand
that I can contact in sorting out the mess.
Oh, regardig mess: We need a coordinator for l10n-kde4 more for anything else.
That module is very, very big, and it is currently almost completely
unorganised. It seldomly (read: never) compiles. many languages are rotting,
many are hopelessly behind module renames/movals/additions/deletions.
for the record: it is something around 2GB in size, which is ten times (!) the
size of all of the rest of KDE together.
> Anyway... something to think about for the near future.
Please be more precise on the how and why in the future, thanks.
More information about the release-team