[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-04 13:21:31
Message-ID: 200601040821.31887.erik () binghamton ! edu
[Download RAW message or body]

Onsdag 04 januar 2006 07:33 skrev Lauri Watts:
> Just to be really clear: We should work on all documentation only in trunk
> for the near to mid-term future (with the obvious exception of extragear
> apps with their branches, and possibly koffice and kdevelop.)


I think a good work flow would be the following
1. stable is almost always frozen for docs and for gui
2. trunk is never frozen, for docs or for gui.
3. stable is unfrozen for a week every so often, like some distance before 
every major release, and for a week after every minor release. It should be 
immediately after the release maximizing the time we have to catch up. This 
should be true both for doc and gui, but for gui it should be a mild thaw 
rather than completely unfrozen at the minor releases.

This way the documentation writers get a chance to get their work into a 
release without waiting for ever, and after having had time, and a place, to 
check their work. We would always have newer versions in trunk than in stable 
as it should be. 

Doing it this way does not require much scripting. Whenever doc files have 
been backported you backport your translation po-files.

So the basic idea both for gui and for docs would be that you freeze the 
moment you move stuff back to stable. This is essentially what we did this 
time for gui at the 3.5 release, and it worked well.

Translators have the opportunity to do some translating in trunk all the time 
so they can catch up in stable just by moving po-files back after the 
unfreezes.

The documentation writers do not have to tell anybody whether they are working 
on the next major or the next minor version. If it is the next major version 
they just do not move it back into stable until it is almost time for the 
next major release.

The principle should hold for extragear as well. At the point you normally 
freeze, you move your stuff back to stable.

As I have said before, the drawback is that you can not develop documentation 
for 3.5.1 and 4.0 at the same time in SVN, but how many do that anyway.

We would also avoid the present mixture of back- and forward porting.

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