On Friday, December 27, 2013 5:44:24 AM UTC-8, RjOllos wrote: > > > > 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. >
Also, my plan is to continue to move low risk tickets into the milestone if I have changes ready, until i hear that someone is ready to make the release happen. For example, http://trac.edgewall.org/ticket/10029 We can always kick these tickets out if the changes haven't been committed but we are ready to proceed with the release. Let me know if there is a better approach. -- 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.
