Hello Ryan, On 2013-12-15 9:28 AM, RjOllos wrote: > Hi, I just wanted to get some thoughts on when might be a good time to > do the next release. There are a few tickets left in each milestone, but > those could be quickly closed or moved forward if we wanted to move > towards a release. >
As I see it, the main issue here would be the translations. There's a great amount of new or updated translations on Transifex, but they haven't been integrated yet. The "ideal" model I had in mind for working with Transifex hasn't happened (beyond french and japanese), and that model was to have a language maintainer being both the Transifex team coordinator and the Trac committer. The "second best" way was to have a process in place for regularly integrating all the changes from Transifex into Trac, and this hasn't worked out either, as it's quite a lot of work and I haven't been able to keep the pace with that. There were two things that prevented us to fully automate this integration. One was that we still got the occasional direct commits from translators, and therefore integrating updates from Transifex required some kind of manual merge (as described in [1]). We could get rid of this problem by enforcing the updates to come exclusively through Transifex. The second issue was that as sometimes we would get changes only in 0.12 or 1.0, it was tempting to use the normal "merge upward" facility in order to get these translations on the other branches and trunk... Not only this isn't trivial to do (it needs the same kind of "normalization" steps as described in [1]), but having to maintain and update 3 sets of mostly similar message catalogs on Transifex is also a burden for translation contributors. I recently had the idea to change the approach here: instead of having 3 releases on Transifex, we could have a single "pool of live translations", i.e. the collection of all messages from 0.12-stable, 1.0-stable and trunk. We could make that pool live in /l10n at the root of the repository and I believe we could maintain that automatically: merging the 3 message catalog templates and all the message catalogs, and only have that on Transifex; the other way round, we could update the catalogs in a given branch with only the messages from the pool for which the message ids are in the corresponding template (.pot) file of the branch. Less work for translators, and an easy way to solve the merge problem (the only thing we would lose is the ability to have different translations in different branches for the same message id, not a real problem I believe). Does this sound like a good idea? Even if would go for doing things this way, it wouldn't come for free either and I admittedly won't have time to implement that myself for yet another bunch of months, so this shouldn't hold the release(s). I think most users would be pleased with a point release as it stands now, with the promise that the next release will integrate all the updated translations. > Mostly, I wanted to make sure that I wasn't holding up a release by > continuing to move tickets into the milestones. My approach has been to > continue to work tickets until someone has a chance to do the release. Unless there are some which you consider to be blockers, we can "freeze" these milestones anytime by creating the new ones (0.12.7, 1.0.3, 1.1.3) and move the tickets there as appropriate. Besides, doing so gives a strong hint that a release is really on the way :-) -- Christian [1] - http://trac.edgewall.org/wiki/TracL10N/Transifex#Checkingthestatus -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/groups/opt_out.
