Modules and Maintainers
winter at kde.org
Thu Dec 20 22:36:34 CET 2007
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
> 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
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
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.
More information about the release-team