bug in es_AR_update and branch layout
6 views
Skip to first unread message
MestreLion
Apr 5, 2012, 8:20:51 PM4/5/12
to endgame-sin...@googlegroups.com
Phil, I just found a small syntax bug in the updated es_AR translations. I've fixed it, and also improved error handling to make it more robust for future syntax errors in translation files.
Before posting the fixes, I ask: you would be OK in amending the original update_es_AR commit? This way we can have a single commit for a flawless, new es_AR "language pack", and the "robust handling" code can be incorporated later in my improve_lang_handling branch
My proposal is:
A M1
... --o----X
\
\ M2
\----o . . . . . . . . . . M3'
\ /
\----B1----B2---B3/M3---C1---C2--C3
\
\---XDG1---XDG2
\
\--- other stuff
Where:
A - Tel Aviv commit, previous commit from current Master
M1 - Current Master, es_AR with bug. To be discarted
M2 - Proposed new Master, es_AR with no bug
Bx - commits from my public/improve_lang_handling. It will have the refactoring, bugfixes, cleanup, robust code, etc... everything but the new 118n stuff
M3/M3' - The new Master after merge, depending whether you Fast-Forward or not
Cx - The testing/118n branch, depends on lang_handling, but still under active development
XDG1+2 - Both XDG branches, rebased together on top of lang_handling, so new master can be FF'ed to it
other stuff - other topic branches that may be merged independently from anything else
So, what do you think about this layout? If you agree, I can publish the rebased branches in the weekend.
cya,
ML
Before posting the fixes, I ask: you would be OK in amending the original update_es_AR commit? This way we can have a single commit for a flawless, new es_AR "language pack", and the "robust handling" code can be incorporated later in my improve_lang_handling branch
My proposal is:
A M1
... --o----X
\
\ M2
\----o . . . . . . . . . . M3'
\ /
\----B1----B2---B3/M3---C1---C2--C3
\
\---XDG1---XDG2
\
\--- other stuff
Where:
A - Tel Aviv commit, previous commit from current Master
M1 - Current Master, es_AR with bug. To be discarted
M2 - Proposed new Master, es_AR with no bug
Bx - commits from my public/improve_lang_handling. It will have the refactoring, bugfixes, cleanup, robust code, etc... everything but the new 118n stuff
M3/M3' - The new Master after merge, depending whether you Fast-Forward or not
Cx - The testing/118n branch, depends on lang_handling, but still under active development
XDG1+2 - Both XDG branches, rebased together on top of lang_handling, so new master can be FF'ed to it
other stuff - other topic branches that may be merged independently from anything else
So, what do you think about this layout? If you agree, I can publish the rebased branches in the weekend.
cya,
ML
Phil Bordelon
Apr 5, 2012, 10:13:02 PM4/5/12
to endgame-sin...@googlegroups.com
On 04/05/2012 07:20 PM, MestreLion wrote:
> Phil, I just found a small syntax bug in the updated es_AR translations.
> I've fixed it, and also improved error handling to make it more robust for
> future syntax errors in translation files.
>
> Before posting the fixes, I ask: you would be OK in amending the original
> update_es_AR commit? This way we can have a single commit for a flawless,
> new es_AR "language pack", and the "robust handling" code can be
> incorporated later in my improve_lang_handling branch
> Phil, I just found a small syntax bug in the updated es_AR translations.
> I've fixed it, and also improved error handling to make it more robust for
> future syntax errors in translation files.
>
> Before posting the fixes, I ask: you would be OK in amending the original
> update_es_AR commit? This way we can have a single commit for a flawless,
> new es_AR "language pack", and the "robust handling" code can be
> incorporated later in my improve_lang_handling branch
I am not in favour of rebasing the public tree. It's no problem having a
"fix patch." No one's going to fire you for getting something wrong :)
P
Reply all
Reply to author
Forward
0 new messages