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 ). We could get
rid of this problem by enforcing the updates to come exclusively through
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 :-)
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.
Presumably, changes in trac/locale should not be merged?
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.
Milestone 1.0.2 now has more tickets than major release 1.0 and it is now 16 months overdue !! We would like to update our Trac instance to 1.1.2 in August 2014.
When is it planned to release Trac 1.0.2 and Trac 1.1.2?
I'd also support a much simplified process, if reasonably possible via automation, otherwise via documentation and reduced flexibility / quality if needed.
I'm personally not a user / contributor of translations and have never looked into that process, so maybe I'm totally wrong, but for example to me it would be acceptable to drop string freeze delays and force translators to use SVN etc. (or whatever process reduces complexity the most **for the release coordinator**).
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@example.com.
To post to this group, send email to trac...@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.
On 2014-07-26 7:20 AM, RjOllos wrote:
> On Friday, July 25, 2014 1:19:36 AM UTC-7, RjOllos wrote:
> It seems I have let this drag on through the week. I'm currentlyI'll be able to have some time on Sunday as well, maybe we could go
> down to two tickets: #11684 and #10018. The latter is the important
> one since I think some regressions have been introduced. I'm aiming
> to resolve those by Saturday.
> Additionally it looks like Jun is working 3 Subversion-related
> tickets for 0.12.6. There are two more tickets, #11650 and #10207,
> both of which can probably be moved forward.
> I'll follow-up on Saturday or Sunday to see what the next steps
> might be.
through the steps of creating some beta1 releases first.
In my setup (using Trac 1.0), we have several projects, each of them
inheriting from a common trac.ini.
In the [inherit] section of the common trac.ini, I have a
plugins_dir = /etc/forge/plugins
That /etc/forge/plugins is empty.
I use apache + mod_wsgi, and for each project, I set
trac.env_path to /var/forge/projects/<project_name>/trac
I added a plugin in the 'local' plugins dir of one of this project.
(so in /var/forge/projects/<that_project>/trac/plugins)
Despite what I expected, this plugin is available to all projects
(and it is listed in the 'About Trac' page of all projects).
Is that the expected behavior ? Did I something wrong ?
Note: I have same behavior with 1.1.1, and afaik the "private" plugin
was hidden from other projects in Trac < 1.0 (but I may be wrong, it
was 3 years ago...)
Thx for your great work !
What is the news with the release? Are you stuck again somewhere? How can I help?
The latest beta1 packages are available on the Downloads site (1):
There seems to be a question as to whether the installer for the win64 platform is neeeded (2).
On Sep 23, 2014 12:23 PM, <ryan.j...@gmail.com> wrote:
> On Friday Sep 19, 2014 at 8:35 PM, falkb <fbretts...@baumer.com>, wrote:
> I tried http://download.edgewall.org/trac/Trac-1.0.2beta1.win32.exe
> on Win7 64bit, but the installer hangs after I've chosen the pathes of
> Python and install dir and went to the next page and clicked on the Next
> button. Then I tried the 1.0.2beta amd-64bit installer on the same machine
> (although I don't have an AMD CPU), but a click on the first Next button of
> the installer just says "No python installation found in the registry" and
> returns to the installer page where's just "Cancel" works then and aborts
> the installation.
> CU, F@lk
Thanks for testing. I built the packages with Python 2.7 on windows 8. We might need to create them again. I won't have an opportunity to test on Windows and debug potential issues until Oct 9th, so hopefully someone else can try. I should be able to test on Linux soon
what has happend to the Release again? Where are we now? What can we do to lift the stalled plane up again? I didn't understand whether you changed something in the Windows installers or not.
Do you know if amd-64bit is only for the AMD CPU or is it for all 64bit CPUs?
amd-64 is for all x86-64 CPUs.
Both the win32 (on Win7 64bit, Intel CPU, Python x86 is installed) and win-AMD64 (on Win8 64bit, Intel CPU, Python x86-64 is installed) versions of the 1.0.2beta installers worked for me.
Am Montag, 6. Oktober 2014 21:14:00 UTC+2 schrieb Peter Suter:
amd-64 is for all x86-64 CPUs.
I see. Could you please rename it to perhaps just "64". That "amd" is misleading and unusable.
As the installer didn't work here, I suspected the reason is that it is designed for AMD CPUs, only.