[kde-doc-english] Sorting out backports/string freeze schedule

[T.C. Hollingsworth]

On 8/15/11, Burkhard Lück <lueck at hube-lueck.de> wrote:
> Am Montag, 15. August 2011, 15:32:57 schrieb T.C. Hollingsworth:
>> I just realized that Kate's new folding stuff shouldn't go into 4.7,
>> like all of the other changes in branches/work/doc so far.
>>
>> How should I go about separating these out so they don't get
>> backported?  Commit them to git separately?  Hold them in
>> branches/work/doc until around 4.8 release time?
>>
> If that stuff is ready please commit to git master and add a note to
> http://techbase.kde.org/Projects/Documentation/KDE4_(health_table)
> stating the version (kde 4.8) and please add a comment like "Do not backport
> to 4.7".
> If there are updates also valid for 4.7 please try do commit separately so
> it
> is possible to backport that. CC this list or add the info to the Doc Health
> table.

Sounds good.

Unfortunately Adrian already committed the new folding stuff, but I
guess I can add a note to the health table that indicates not to
backport that particular commit.

>> I wouldn't mind merging them into the branch myself if I could be
>> told/be pointed at a schedule of when it is safe to do so.
>
> You are not allowed to merge any single character change in the docs to 4.7,
> this branch is completely string frozen.
>
>> Come to
>> think of it, I've looked around kde.org before for a 4.7 series string
>> freeze schedule and couldn't find one.  That would be nice for
>> planning out ongoing work to the plugins chapter and other docs
>> anyway.
>>
> For 4.8 we'll have a release schedule similar to
> http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule
>
> Let me explain the string freeze issue:
>
> Scripty aka the i18n tool chain and the translations teams handle only two
> branches:
> 1) trunk - Translations in trunk/l10n-kde4 and code/docs in trunk/[KDE|
> extragear|playground] or the corresponding git branches
> 2) stable - Translations in branches/stable/l10n-kde4 and code/docs in
> branches/[KDE/4.x|extragear] or the corresponding git branches
>
> Branch is always string frozen, trunk at certain times according to the
> release schedules.
>
> To break GUI string freeze in branch you always need approval from the
> translators (kde-i18n-doc) and usually you'll get that.
>
> Breaking DOC string freeze in branch is impossible for anybody - except for
> the translators under certain rules
> (see http://lists.kde.org/?l=kde-i18n-doc&m=126323170811427&w=2).
>
> Btw I am a bit confused about your plans with the KWrite documentation in
> work/doc.
>
> Would you mind to elaborate please?
>
> You splitted the kwrite docs into sevaral parts similar to kate's, If the
> splitted kwrite docs go into git, the existing doc translations have to be
> splitted by the translation team as well.

Well, most of the new stuff is an exact copy from Kate, and I was
hoping splitting it would make copying translations easier, since they
should already be translated for Kate and the only change in either
was flipping &kate; to &kappname;.  (Not to mention that a monolithic
docbook with everything in there now would be ridiculously long.)

But, I've been thinking about it, and even though everything I copied
over is technically valid for KWrite, a great deal of it will probably
never be used by someone with just KWrite installed.  (e.g. anybody
who would be writing highlighting XML for katepart probably will have
kate installed anyway, so we could just point to the kate docs for
that).  I think there's one section of advanced.docbook that would be
better suited in part.docbook, and then that could be elided from
KWrite too.  The vi mode stuff could probably go as well.  I'm not
entirely sure about regular expressions, methinks there are some
people with just KWrite who might find that useful.

The only thing I really want to keep is part.docbook.  That had some
stuff I linked to in kate/configuring.docbook but had to remove on
sync to kwrite because it didn't exist there (as you noticed when
translating).

At any rate, if it will make translating easier, I can certainly
revert KWrite to one docbook and just copy/paste the much smaller
amount of new stuff we'll keep in there instead.  As I said in the
previous thread about this, I'm trying to make things easier for
translators with all this new stuff coming over from kate but wouldn't
be surprised if I'm overthinking things and actually making it harder.
 ;-)

-T.C.