On Wednesday, January 1, 2014 1:53:10 PM UTC-8, RjOllos wrote: > > On Tuesday, December 31, 2013 8:14:13 PM UTC-8, RjOllos wrote: >> >> >> >> 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. >> > > > There are some changesets eligible for merge to the trunk that look like > they should be merged. I just wanted to check before taking action on > merging these: > > http://trac.edgewall.org/changeset/11795 > http://trac.edgewall.org/changeset/11804 > http://trac.edgewall.org/changeset/11820 >
These changesets have been merged: http://trac.edgewall.org/log/?revs=11795%2C11804%2C11820 > Presumably, changes in trac/locale should not be merged? > I'm less certain of how to handle these, so I've left them for now: 0.12-stable -> 1.0-stable: http://trac.edgewall.org/log/branches/0.12-stable?revs=11792%2C11807%2C12347-12348 1.0-stable -> trunk: http://trac.edgewall.org/log/branches/1.0-stable?revs=11696%2C11718%2C11720-11724%2C11793%2C11801 -- 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.
