Modules and Maintainers

[Dirk Mueller]

On Wednesday 12 December 2007, Allen Winter wrote:

> For 4.x, where x >=1, I think we need to require maintainers for all our
> modules.

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 
drawback?

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 
perform. 

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 
how. 

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. 

Greetings,
Dirk