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 [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.
