On Wednesday, January 15, 2014 12:37:26 AM UTC, RjOllos wrote: > 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 > >
It's heartening to see so much activity on the Trac timeline: http://trac.edgewall.org/timeline But I'm very keen to see a release of 1.0.2: it's been more than a year since the last release of 1.0. Do you have an idea of when the next release might be? There only seem to be a few tickets outstanding. The suggested 3-4 releases a year would be great. Thanks -- 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.
