Modules and Maintainers

[Albert Astals Cid]

A Dijous 20 Desembre 2007, Dirk Mueller va escriure:
> 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.

Well, i'm lately acting as a bit of coordinator there, i can take the official 
name, will that give me more karma or just more headaches :D

I will make sure l10n-kde4 compiles before next monday, and will check it 
regularly.

If noone disagrees me being the official coordinator (with the ocasional abuse 
of Chusslove and Pino to help me ;-) of l10n-kde4 say it before 24 hours, as 
that'll be when i announce it in the kde-i18n-doc list.

Albert

>
> > Anyway... something to think about for the near future.
>
> Please be more precise on the how and why in the future, thanks.
>
> Greetings,
> Dirk
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team