[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: K3b - my apologies
From:       Jeroen Wijnhout <Jeroen.Wijnhout () kdemail ! net>
Date:       2004-01-27 13:35:41
Message-ID: 200401271435.41327.Jeroen.Wijnhout () kdemail ! net
[Download RAW message or body]

On Tuesday 27 January 2004 13:36, Malcolm Hunter wrote:
> > I can't force them to do that (I tried, believe me). On the other hand,
> > I'm not going to discard their work if they send me an updated kile.po
> > file.
>
> Couldn't you email the translation team coordinator to let him know, so it
> can be committed to CVS?

Ok, I will do that in the future. Allthough I would still like to have the 
possibility of committing last minute fixes (say a few days before release) 
in the kde-i18n module. In that case I will CC the coordinator in the CVS 
commit, would that be acceptable?

> > Yes, the current situation leads to various problems.
>
> There's no point having extragear if developers treat it like sourceforge.

I beg your pardon? The KEG module is especially for modules that release on 
their own. This gives problems in the current setup. Not because people are 
stubborn or uncooperative. No, just because the KDE infrastructure is 
designed around the core parts of KDE (libs, base, etc) and not around KEG.

The questions is: How do we deal with these problems?

For example, how should the team coordinators deal with the branches in KEG? 
Every app can have their own branches (for example Kile has a branch_1_6, 
branch_1_5 etc.). If the coordinators are the ones who commit the 
translations into CVS, they also have to know about the branches. In fact 
scripty needs to know about the branches as well.

So, I agree with Andrea, we should think about a new policy (if there was a 
policy at all).

best,
Jeroen
-- 
Kile - KDE Integrated LaTeX Environment
http://kile.sourceforge.net

[prev in list] [next in list] [prev in thread] [next in thread]