On Tuesday, December 17, 2013 11:08:34 AM UTC-8, RjOllos wrote: > > On Sunday, December 15, 2013 1:30:58 AM UTC-8, cboos wrote: >> >> 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 >> > > Thank you both for the feedback. As far as the tickets I'm working, I can > wrap them up by the end of this week. I'd be interested to hear from Jun > and Peter if that timing would work well with regard to any open tickets > assigned to the milestones that they would like to resolve before the > release happens. > > - Ryan > > It looks like all the tickets are closed now. Please let me know if there is anything I can do to help with the release.
As for 0.12.7 / 1.0.3 / 1.1.3, I tentatively set the due date to April 1st. If others are on-board, I like the idea of aiming for a shorter release cycle that leads to maybe 3-4 releases per year, and would scope my work accordingly. -- 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.
