Modules and Maintainers

[Allen Winter]

On Thursday 20 December 2007 11:16:17 Dirk Mueller wrote:
> 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.

That's not a good enough reason to have a module.

> I also don't think that mixing kdeutils and kdeaccessibility is a good idea.

That's not what I'm suggesting.  I'm suggesting that we try to find a 
coordinator for all our modules.  If not, then consider eliminating
those modules by moving their apps into existing modules already
with a coordinator, or into extragear, and failing that.. eliminate them

> Keeping Accessibility separate has advantages, and it is what users expect (I think). 

Agree.    And I mistyped.. I meant kdeadmin and not kdeaccessibility.
Luckily we have Gunnar Schmi Dt looking after kdeaccessibility.

> 
> 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. 
> 
We'll only move stuff into extragear that is well maintained but currently
resides in a module which is drifting aimlessly. :)  But you might be correct.
Obviously, I think we should try very hard to find module coordinators.

> Also, the actually difficult modules like kdeadmin or pim/network are not 
> mentioned in your proposal. Why is that so?
> 
I mistyped as I said above.  I should have mentioned kdeadmin.
kdepim and kdenetwork have coordinators (me and Urs).. that's
why I didn't mention them.  We can discuss whether the existing
coordinators are doing a good job in another thread.

> > 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. 
> 
It was handled, but poorly.  By me.
And it wasn't fun.  And I got yelled at by at least 4 different people for
the way I handled it.  And that's why I thought it would be easier/better to
have a person responsible for these decisions within the module.

> 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.
> 
There are lots and lots of decisions to be made all the time.  And everyone is on
a different  timeline with a different set of priorities.  I have no solutions on how
to improve communication.

> 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. 
> 
In the case of Kompare, I would have been happy to know of 1 person I could
go to with the issue.  But there was 0.  I'm happier with N (where is a smallish number
and can be handled by a mailing list) than 0.

And we already have a coordinator for many of our modules and I feel like
this has been a benefit both to the Project and to the Release Team.
But I could be wrong.

For example, aseigo got rid of kdeaddons.