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

List:       kde-i18n-doc
Subject:    Re: [RFC] Documentation, take 2
From:       Erik =?iso-8859-1?q?Kj=E6r_Pedersen?= <erik () binghamton ! edu>
Date:       2006-01-07 16:02:02
Message-ID: 200601071102.03247.erik () binghamton ! edu
[Download RAW message or body]

Torsdag 05 januar 2006 11:24 skrev Nicolas Goutte:
> > 2. trunk is never frozen, for docs or for gui.
>
> I do not think that "never" is possible. At most it can be reduced to a
> minimum but I do not think that it can be always avoided.

The point was supposed to be that nothing gets released without having been 
through stable where it is frozen, so I do not understand your point.

> This would mean that smaller translation teams would never catch up, as
> there will always be new stuff to translate. However perhaps it is a
> drawback that we have to accept.

I am not sure what smaller translation teams means, do you mean smaller than 
one member like the Danish one. As far as I can tell the Swedish team has 
little more than one member too. There will always be stuff to translate in 
trunk, but you can certainly catch up in stable which is what matters since 
that is what gets released
>
> I fear that this is not going to work. In the two "unfreeze" weeks, nobody
> has ported to KDE 3.5.x the up-to-date documentation that was in trunk.

Well obviously the developers have to be educated that the system is that 
everything goes to stable at the moment of freezing for this to work. I 
believe somebody suggested we should make a proposal on the developer list.

It may be hard for the developers to understand, but one of the experiences I 
had was that digikam all of a sudden showed up in stable. I translated it and 
got a letter from a developer, that this was something that would probably 
never get released. I am not able to remember all the different possibilities 
for the different programs. kdvelop apparently at the moment exists in a 
development version in stable and in an undefined version in trunk. I just 
noticed that kwrite is much bigger in stable than in trunk. Why is that. 

Obviously this can not be made to work without discussion with the developers, 
but I do think my proposal would be a big improvement on the present 
situation that at best can be descrobed as confusing, and if I understand 
Lauri correctly is actually harmful for the documentation writers.

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