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 Presumably, changes in trac/locale should not be merged? -- 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 trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/groups/opt_out.
