[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of the sarge branch?



Quoting Frans Pop (aragorn@tiscali.nl):

> But merging changes from trunk to sarge will still be possible even if you 
> release from sarge.
> If a diff that is merged from trunk contains any kind of translation 
> updates, that would break the master PO file mechanism. This was the 
> reason the update scripts had to be disabled for RC3.
> 
> So, if we keep the master PO file mechanism, I think we should always 
> exclude any changes in translations when merging changes from trunk.

Well, if changes are merged from trunk, then we can safely assume that
indeed they do no include string changes, right?

So, for packages we are doing this, the strings are already there in
the sarge master files.

The only problems which may arise are the case where a master file is
updated in trunk, but not in sarge. 

In that case the individual PO files coming from trunk are newer than
the sarge ones...but would be replaced by those from the outdated
master file.

So, my conclusion is that we should keep the sarge master files synced
with the trunk ones.

What I imagine is a scheme where translators only commit to trunk
master files. The changes are then merged to the sarge files by a
script run from gluck and l10n-sync is run on sarge branch.

> IMHO we would significantly reduce the risk of errors if we drop the use 
> of master files in the sarge branch.


This is another possibility, yes. 

But this will need translators to make updated to individual PO files
for sarge packages in case they correct errors which affect both
branches. In that case, the error correction will never go to sarge if
the package is released directly from sarge without being merged from
trunk first.

We can avoid that by *always* pick up PO files from trunk even when
releasing from sarge directly with no merge from trunk. However, this
adds complication to the release process and I'm afraid this would be
forgotten in some cases.



Another advantage of the first proposed solution is that we will have
an easy way to see the packages which need translation updates in the
sarge branch (because they have been updated from trunk). So, this
allows rebuilding them for a possible point release of the sarge
installer, thus keeping these point releases with the translation
enhancements we have in trunk.


I'm currently testing what happens when l10n-sync is run on sarge....I
have a day off today, so if I don't need too much time for lawnmoving,
repair broken stuff in the house, driving kids at school,
I may be able to do these tests...:)






Reply to: