Git translation branch policy change: merge with and from stable/2.16

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Git translation branch policy change: merge with and from stable/2.16

John Mandereau
Dear translators and developers,

From now on, translation branch at the repository on Savannah should no
longer be merged with master and into staging; instead, it should be
merged with stable/2.16.  This will be so until activity on stable/2.16
drops, that is, when changes in documentation cease to be backported, or
when you translators have reached some well-defined goal (for example,
achieve a full translation of some manual), or when 2.16 releases stop.
Unless there is a plan to merge stable/2.16 into master, commits
regarding translations should be backported from translation to staging
branch; I'm taking over this task now, but all people who are used to
merge translation and staging/master (Francisco, Jean-Charles) and feel
comfortable with cherry-picking may do this.

As a consequence, extreme care must be taken when merging translation
branch into stable/2.16: build must be done from scratch in a build
directory separate from source tree.  I take over from this task and
will give notice if I have difficulty doing so frequently enough (say,
twice a week).  Merging translation and stable/2.16 should be done with
the same care.

Best,
John Mandereau



Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/8/15 John Mandereau <[hidden email]>:

> From now on, translation branch at the repository on Savannah should no
> longer be merged with master and into staging; instead, it should be
> merged with stable/2.16.  This will be so until activity on stable/2.16
> drops, that is, when changes in documentation cease to be backported, or
> when you translators have reached some well-defined goal (for example,
> achieve a full translation of some manual), or when 2.16 releases stop.
> Unless there is a plan to merge stable/2.16 into master, commits
> regarding translations should be backported from translation to staging
> branch; I'm taking over this task now, but all people who are used to
> merge translation and staging/master (Francisco, Jean-Charles) and feel
> comfortable with cherry-picking may do this.

Allright,

> As a consequence, extreme care must be taken when merging translation
> branch into stable/2.16: build must be done from scratch in a build
> directory separate from source tree.  I take over from this task and
> will give notice if I have difficulty doing so frequently enough (say,
> twice a week).  Merging translation and stable/2.16 should be done with
> the same care.

and allright. I have many pendant tasks as a plain translator; if I
need something more than pushing to translation to be done, I'll say.

Thanks John,
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

John Mandereau
Hi Francisco,
Il giorno sab, 18/08/2012 alle 23.56 +0200, Francisco Vila ha scritto:
> and allright. I have many pendant tasks as a plain translator; if I
> need something more than pushing to translation to be done, I'll say.

If your pendant tasks had master branch as upstream, you should be fine
with completing them and pushing them to translation with this new
policy, because at some point after you went to vacation, stable/2.16
was branched out of master, and then translation and stable/2.16 have
been merged together and are equal as I'm writing this.

Best,
John



Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/8/19 John Mandereau <[hidden email]>:

> Hi Francisco,
> Il giorno sab, 18/08/2012 alle 23.56 +0200, Francisco Vila ha scritto:
>> and allright. I have many pendant tasks as a plain translator; if I
>> need something more than pushing to translation to be done, I'll say.
>
> If your pendant tasks had master branch as upstream, you should be fine
> with completing them and pushing them to translation with this new
> policy, because at some point after you went to vacation, stable/2.16
> was branched out of master, and then translation and stable/2.16 have
> been merged together and are equal as I'm writing this.

Hi John,
as things are today, can we keep doing the usual merges of
translation-->staging and master-->translation?

Translators: I am very busy at home these days. I can perform those
tasks on Sep 10 at soonest.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/9/8 Francisco Vila <[hidden email]>:
> Hi John,
> as things are today, can we keep doing the usual merges of
> translation-->staging and master-->translation?
>

I still had no response, but now I have a request. The translation
branch is still in 'stable' status. I think it should be kept so for a
while, i.e. not to merge master into translation until a new 2.16.x
stable is released. I believe this is the path to go because no
translation/stable branch has been created, therefore if we want to
sync our translations to master, we have no way of knowing what to
translate and what not to.

After next 2.16.x, we can merge master into translation and go on with
translation of development branch.

Right?
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/9/13 Francisco Vila <[hidden email]>:
>  therefore if we want to
> sync our translations to master, we have no way of knowing what to
> translate and what not to.

Sorry, I meant

'If we want to sync our translations with stable, after merging master
(which is development branch) into translation we'll have no way of
knowing what to translate and what not to.'

--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

John Mandereau
In reply to this post by Francisco Vila
Il giorno gio, 13/09/2012 alle 10.44 +0200, Francisco Vila ha scritto:
> 2012/9/8 Francisco Vila <[hidden email]>:
> > Hi John,
> > as things are today, can we keep doing the usual merges of
> > translation-->staging and master-->translation?
> >
>
> I still had no response,

I think the message that started this thread stated it clearly: "From
now on, translation branch at the repository on Savannah should no
longer be merged with master and into staging; instead, it should be
merged with stable/2.16."


>  but now I have a request. The translation
> branch is still in 'stable' status. I think it should be kept so for a
> while, i.e. not to merge master into translation until a new 2.16.x
> stable is released. I believe this is the path to go because no
> translation/stable branch has been created, therefore if we want to
> sync our translations to master, we have no way of knowing what to
> translate and what not to.

Creating a translation/stable branch is easy, but I don't know how
translators would be comfortable with switching between two branches for
translation work (maybe I wouldn't if I worked on translations myself).


> After next 2.16.x, we can merge master into translation and go on with
> translation of development branch.
>
> Right?

You mean 2.16.1, don't you?

The probable frequence of 2.16 releases makes this sound like a good
idea.

As we have already merged stable/2.16 into staging/master, we can do it
again right after 2.16.1, and just after that merge translation with
staging and from master.

John



Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/9/13 John Mandereau <[hidden email]>:
> I think the message that started this thread stated it clearly: "From
> now on, translation branch at the repository on Savannah should no
> longer be merged with master and into staging; instead, it should be
> merged with stable/2.16."

Well, right.

>>  but now I have a request. The translation
>> branch is still in 'stable' status. I think it should be kept so for a
>> while, i.e. not to merge master into translation until a new 2.16.x
>> stable is released. I believe this is the path to go because no
>> translation/stable branch has been created, therefore if we want to
>> sync our translations to master, we have no way of knowing what to
>> translate and what not to.
>
> Creating a translation/stable branch is easy, but I don't know how
> translators would be comfortable with switching between two branches for
> translation work (maybe I wouldn't if I worked on translations myself).

We have to choose between fussing around with switching branches or
fussing around with guessing what to translate for stable only. The
former is very difficult but feasible, the latter is almost impossible
is master gets merged on translation.

>> After next 2.16.x, we can merge master into translation and go on with
>> translation of development branch.
>>
>> Right?
>
> You mean 2.16.1, don't you?

Yeah,

> The probable frequence of 2.16 releases makes this sound like a good
> idea.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Federico Bruni-2
In reply to this post by John Mandereau
Il 15/08/2012 19:30, John Mandereau ha scritto:
>  From now on, translation branch at the repository on Savannah should no
> longer be merged with master and into staging; instead, it should be
> merged with stable/2.16.  This will be so until activity on stable/2.16
> drops, that is, when changes in documentation cease to be backported, or
> when you translators have reached some well-defined goal (for example,
> achieve a full translation of some manual), or when 2.16 releases stop.

This also means that all the commits in translation branch will be
backported to 2.16.1, right?

There's no need to disturb David, right?

I'm asking because I've just committed a patch that should be backported:
16bf0d2978f9b18b935e22a4c8e31e4b2c321797

Branching makes me still scratch my head (especially at night).
--
Federico


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/9/25 Federico Bruni <[hidden email]>:
> I'm asking because I've just committed a patch that should be backported:
> 16bf0d2978f9b18b935e22a4c8e31e4b2c321797

Should it be backported because it translates recent work from 2.17?
Master has not been merged on translation since before 2.16.

--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Federico Bruni-2
2012/9/25 Francisco Vila <[hidden email]>:
> 2012/9/25 Federico Bruni <[hidden email]>:
>> I'm asking because I've just committed a patch that should be backported:
>> 16bf0d2978f9b18b935e22a4c8e31e4b2c321797
>
> Should it be backported because it translates recent work from 2.17?
> Master has not been merged on translation since before 2.16.
>

Ok, I misused the term "backport". The patch translates from current
translation branch, so it will be included in 2.16.1 for sure.
I asked just to be sure...

I don't know if David will backport some documentation changes.
I think that issue 2791 should be backported to 2.16.1, but it's not
been marked with label:Backport
David, what do you think about it?


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

John Mandereau
In reply to this post by Federico Bruni-2
Il giorno mar, 25/09/2012 alle 00.51 +0200, Federico Bruni ha scritto:

> Il 15/08/2012 19:30, John Mandereau ha scritto:
> >  From now on, translation branch at the repository on Savannah should no
> > longer be merged with master and into staging; instead, it should be
> > merged with stable/2.16.  This will be so until activity on stable/2.16
> > drops, that is, when changes in documentation cease to be backported, or
> > when you translators have reached some well-defined goal (for example,
> > achieve a full translation of some manual), or when 2.16 releases stop.
>
> This also means that all the commits in translation branch will be
> backported to 2.16.1, right?

There's not backporting as such with translations now, because it's
policy that translation branch is merged with and from stable/2.16.


> There's no need to disturb David, right?

No, but until 2.16.1 is out you can pester me for merging translation
into stable/2.16 if I don't do it often enough.


John



Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
In reply to this post by Federico Bruni-2
2012/9/25 David Kastrup <[hidden email]>:
> Obviously, documentation improvements concerning 2.16-only material are
> quite eligible as they will not disrupt 2.16 operation and compatibility
> itself.  One just needs to be careful with stuff concerning manual
> structure, web functionality etc in order not to render the manual
> inconsistent.
>
> If somebody volunteers to do this selection process (possibly also
> committing to the 2.16 stable branch) instead of me, it will certainly
> save me some work.

At first, I can not see what amount of translation work already in
2.16 is _not_eligible to be cherrypicked to staging right now and
become a part of the 2.17 releases. Possibly all that currently is in
translation and was not there before the 2.16 fork, could equally be
in staging.

The reason being that translators do not have a reference of what new
material is in 2.17 and therefore we'll translate from the latest
stage of translation, and that is 2.16.

New 2.17 translation work can not be pushed to translation branch
until we close the door to 2.16 because we don't have a translation
branch for unstable which is distinct of that we have for stable. Or,
do we? I think we should. For 2.18, I respectfully demand to fork
stable and its own translation branch at the same time. With our
current system, translations of the few first 2.17 releases are
outdated and there is no easy possibility of updating them, other than
pushing directly to staging.

--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/9/25 Francisco Vila <[hidden email]>:

> 2012/9/25 David Kastrup <[hidden email]>:
>> Obviously, documentation improvements concerning 2.16-only material are
>> quite eligible as they will not disrupt 2.16 operation and compatibility
>> itself.  One just needs to be careful with stuff concerning manual
>> structure, web functionality etc in order not to render the manual
>> inconsistent.
>>
>> If somebody volunteers to do this selection process (possibly also
>> committing to the 2.16 stable branch) instead of me, it will certainly
>> save me some work.
>
> At first, I can not see what amount of translation work already in
> 2.16 is _not_eligible to be cherrypicked to staging right now and
> become a part of the 2.17 releases. Possibly all that currently is in
> translation and was not there before the 2.16 fork, could equally be
> in staging.
>
> The reason being that translators do not have a reference of what new
> material is in 2.17 and therefore we'll translate from the latest
> stage of translation, and that is 2.16.
>
> New 2.17 translation work can not be pushed to translation branch
> until we close the door to 2.16 because we don't have a translation
> branch for unstable which is distinct of that we have for stable. Or,
> do we? I think we should. For 2.18, I respectfully demand to fork
> stable and its own translation branch at the same time. With our
> current system, translations of the few first 2.17 releases are
> outdated and there is no easy possibility of updating them, other than
> pushing directly to staging.

John, David: do you agree or disagree on anything of the above?

Specifically, do you agree in that translations for 2.17 are stalled
and can not progress because we are stuck in 2.16, and in that all
translations in stable can be ported directly to 2.17?

--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

John Mandereau
Il giorno lun, 01/10/2012 alle 10.01 +0200, Francisco Vila ha scritto:
> John, David: do you agree or disagree on anything of the above?
>
> Specifically, do you agree in that translations for 2.17 are stalled
> and can not progress because we are stuck in 2.16, and in that all
> translations in stable can be ported directly to 2.17?

The problem is, what holds next 2.16 release, which energies are needed
for it?  The policy of syncing translation and stable/2.16 works as long
as there are relatively frequent stable releases, in particular I
thought by this time 2.16.1 would already be out.  If 2.16.1 can't be
out very soon, it's probably best to merge stable/2.16 and translation a
last time, then merge stable/2.16 into staging, then sync translation
with staging/master again as usual.

Best,
John



Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/10/1 David Kastrup <[hidden email]>:

> Most of the already released material (in 2.17) flagged "Backport" is
> pretty obvious.  But if you take a look at
>
> <URL:http://code.google.com/p/lilypond/issues/list?can=1&q=Fixed_2_17_0+OR+Fixed_2_17_1+OR+fixed_2_17_2+OR+Fixed_2_17_3+OR+Fixed_2_17_4>
>
> you'll see that there are a lot more one can feel rather ambiguous
> about: often they fix long-standing bugs, or make crucial performance or
> usability improvements.  In the interest of a _stable_ release series,
> one should better leave them out.  But that's a judgment call, and there
> is no really "correct" choice.  So the "energy" that is needed for it is
> to muddle through with creating a release with known problems, creating
> something that is least likely to cause new regressions.

but code.google.com/p/lilypond/issues/list?can=1&q=label%3Dbackport+type%3Ddocumentation
is empty, so we translators should be able to go on working on 2.17.
We currently can't.

> I hope this gives you a better feeling for the path that seems sensible
> for the translation and documentation work to take.

We are stalled because there is no translation branch for 2.17 and all
released 2.17 versions include outdated translations which we can't
update. And pendant translation work for 2.17 is not going to stop
growing. Sorry, that can sound like selfish, I could be wrong, but
backport issues and blocking of 2.16 are irrelevant from the
translation point of view.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Jean-Charles MALAHIEUDE
Le 01/10/2012 15:08, Francisco Vila disait :

> 2012/10/1 David Kastrup <[hidden email]>:
>> Most of the already released material (in 2.17) flagged "Backport" is
>> pretty obvious.  But if you take a look at
>>
>> <URL:http://code.google.com/p/lilypond/issues/list?can=1&q=Fixed_2_17_0+OR+Fixed_2_17_1+OR+fixed_2_17_2+OR+Fixed_2_17_3+OR+Fixed_2_17_4>
>>
>> you'll see that there are a lot more one can feel rather ambiguous
>> about: often they fix long-standing bugs, or make crucial performance or
>> usability improvements.  In the interest of a _stable_ release series,
>> one should better leave them out.  But that's a judgment call, and there
>> is no really "correct" choice.  So the "energy" that is needed for it is
>> to muddle through with creating a release with known problems, creating
>> something that is least likely to cause new regressions.
>
> but code.google.com/p/lilypond/issues/list?can=1&q=label%3Dbackport+type%3Ddocumentation
> is empty, so we translators should be able to go on working on 2.17.
> We currently can't.
>
>> I hope this gives you a better feeling for the path that seems sensible
>> for the translation and documentation work to take.
>
> We are stalled because there is no translation branch for 2.17 and all
> released 2.17 versions include outdated translations which we can't
> update. And pendant translation work for 2.17 is not going to stop
> growing. Sorry, that can sound like selfish, I could be wrong, but
> backport issues and blocking of 2.16 are irrelevant from the
> translation point of view.
>

Here is a list of commits touching /Documentation without any change to
the code base.  They are mostly typos or removals of bad info or
improvements.  I think all of them should be part of any 2.16.

0a12e59b93bceea2c94c61e5c35b17cd88fb6d8f (David Kastrup)
  Issue 2760: CG wants all engravers to have double-quotes around them

e15e0d22810063b79da891bbf472ecc39d09c02c (Federico Bruni)
  Web: add W3C properties of border-*-radius after vendor ones (2784)

d3b8117dc5f12634c7a093955d3b32f66ce26b5e (Trevor Daniels)
  Doc: NR 3.2.1: clarify titles and \header blocks (2652)

6ce800445921f6f32eeb60bfbf7acf1cdba2f9c1 (Janek Warchoł for Rodolfo
Zitellini)
  add website link to tunefl.com (2660)

5fed61cb3b4f254cac376555734bcf748573ea66 (Francisco Vila)
  Doc: clarify the use of a Scheme engraver.

9d074d78d7c25852afa87005e21c118630f4f83b (Phil Holmes)
  Hard-coded version numbers updated

2cc80f28ca3d5cd956201c6f3bdc25ddeef09b89 (Werner Lemberg)
  [doc] Improve example for unpure-pure-container.

3cd24002639b7b48a9f0c7245101bdb721ce21c0 (John Mandereau for Werner Lemberg)
  Add support for Cyrillic in Texinfo/TeX

e5cee7b0d83b2a4f5be602e02aed91a498e3fcdb (James Lowe)
  Web: Removed note about MacOS Lion not supported

a9a451e2316c2e94815e33d51eb42eaae3649384 (David Kastrup)
  Issue 2826: Let do_yyparse return a value rather than going through
parseStringResult

4c33251402e969f15fa796363fe646dff07b2798 (James Lowe)
  Doc: Typos to LM - Fundamental and tweaks.itely

0fc20deb5b706498d328b1c69836a44a00abec9d (Trevor Daniels)
  Doc: improve footnote documentation (2547)

6f44845de9ce94edf96aac8a4d0c4498eeb35360 (Trevor Daniels)
  Doc: delete obsolete para on two-pass spacing (2828)

e8f2efa8e3cc826f65223c931e42283d973831b5 (Francisco Vila)
  Doc: fix small inaccuracy in notation manual, chapter Chords.'

80ac25965335ba51ace93fe478ce7f7907e4df91 (Trevor Daniels)
  Doc: extend explanation of relative-includes (2558)

f8710cbaf9563515cf383c658a534b5c902897a1 (Trevor Daniels)
  Doc: document \time command fully (2807)

9e605a1bb6644d89cf110f20cb6d46bb0339fca7 (James Lowe)
  Web: Add Elysium to Easier Editing section (2871)


Cheers,
Jean-Charles



Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
Thanks, Jean-Charles. Some comments follow.

2012/10/1 Jean-Charles Malahieude <[hidden email]>:
> Here is a list of commits touching /Documentation without any change to the
> code base.  They are mostly typos or removals of bad info or improvements.
> I think all of them should be part of any 2.16.
>
> e15e0d22810063b79da891bbf472ecc39d09c02c (Federico Bruni)
>  Web: add W3C properties of border-*-radius after vendor ones (2784)

This has nothing to do with 2.16 as web is made from current master.
It is only CSS.

> 6ce800445921f6f32eeb60bfbf7acf1cdba2f9c1 (Janek Warchoł for Rodolfo
> Zitellini)
>  add website link to tunefl.com (2660)

This is a bit different from the above because text in web goes to the
web part of the documentation.

> 9d074d78d7c25852afa87005e21c118630f4f83b (Phil Holmes)
>  Hard-coded version numbers updated

This is only for the search feature in our web.

> e5cee7b0d83b2a4f5be602e02aed91a498e3fcdb (James Lowe)
>  Web: Removed note about MacOS Lion not supported

For the web manual only. These changes are already visible online.

> a9a451e2316c2e94815e33d51eb42eaae3649384 (David Kastrup)
>  Issue 2826: Let do_yyparse return a value rather than going through
> parseStringResult

This is not only documentation. I think this belongs to 2.17

--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Jean-Charles MALAHIEUDE
In reply to this post by Jean-Charles MALAHIEUDE
Le 01/10/2012 21:00, David Kastrup disait :
> Jean-Charles Malahieude <[hidden email]> writes:
>
>> Here is a list of commits touching /Documentation without any change
>> to the code base.  They are mostly typos or removals of bad info or
>> improvements.  I think all of them should be part of any 2.16.
>
> This is _so_ not "without any change to the code base".  How did you
> arrive at this list of commits?
>

I picked them up from a custom view in Gitk (see image).

Cheers,
Jean-Charles

Gitk-View-Newview.png (83K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Jean-Charles MALAHIEUDE
Le 02/10/2012 19:48, David Kastrup disait :

> Jean-Charles Malahieude <[hidden email]> writes:
>
>> Le 01/10/2012 21:00, David Kastrup disait :
>>> Jean-Charles Malahieude <[hidden email]> writes:
>>>
>>>> Here is a list of commits touching /Documentation without any change
>>>> to the code base.  They are mostly typos or removals of bad info or
>>>> improvements.  I think all of them should be part of any 2.16.
>>>
>>> This is _so_ not "without any change to the code base".  How did you
>>> arrive at this list of commits?
>>>
>>
>> I picked them up from a custom view in Gitk (see image).
>
> Looks like you got a list of commits touching /Documentation, regardless
> of whether they touched anything else.
>

Sorry, I did not notice that other files were "hidden" from the list.
I actually use this for having a quick glance at what has changed in
Documentation/ when in the middle of an update with the result of
check-translation.

Cheers,
Jean-Charles


12