Fellow Package Maintainers,
How are you dealing with this ?
I guess f-spot is not the only project maintaining multiple parallel branches, a STABLE one, from which the releases and bugfix releases are created, and a master, open for business, new stuffs, and experimentations.
When we need to correct something on the STABLE branch, we push a new commit over there, then merge the STABLE back to master so it gets the same fixes. That works fine.
But it gets harder with translation commits. Most of the (awesome) translators (well, all except of one) translates the master and commits right there. Then, when it's time to release, I either ignore those translations (and that's seriously annoying for translators who pushed soem work in the .po), or I blindly backport (cherry-pick) the translations back to the STABLE branch and hope that no strings was removed in master's code. Then I merge the STABLE back to master. Both solutions are seriously suboptimal. Really.
I know how this problem is "solved" in most of the GNOME projects by putting deadlines and code freezes, and string freezes, but I guess we're not the only project around with this kind of issue.
The ideal workflow would be to have the translators (hey guys) aware of the STABLE branch, make them translate that branch, have them merge it back to master, and then, optionally, translate the missing/changed strings and commit that to master. I said ideal, cause I'm NOT gonna ask any translator to understand and follow this, be able to maually merge if something goes wrong, etc...
Translators (did I say thanks for your job lately) are already doing an ant job, most of them with no tools but a text editor, and we can't really add any pain to the process.
So, what are you doing in that case. How could we improve the process ?
Comments are open.
1 week ago