Trac 0.12.6 / 1.0.2 / 1.1.2

632 views
Skip to first unread message

RjOllos

unread,
Dec 15, 2013, 3:28:28 AM12/15/13
to trac...@googlegroups.com
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.

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.

Regards,
- Ryan

Remy Blank

unread,
Dec 15, 2013, 5:29:08 AM12/15/13
to trac...@googlegroups.com
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.

Since we don't have a rigid release plan, whenever we feel that a branch
is in a stable state is a good time for a release.

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

I have very little time for Trac nowadays, and I know Christian is
currently pretty busy, too. This means that there won't be any new
releases if no one is poking us with at least some persistence :)

Ideally, we should go through the process together with you, Jun and
Peter, so that you can make the next releases yourselves. It would be a
shame for us to slow you down.

-- Remy

signature.asc

Christian Boos

unread,
Dec 15, 2013, 4:30:58 AM12/15/13
to trac...@googlegroups.com
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

Olemis Lang

unread,
Dec 16, 2013, 9:06:00 AM12/16/13
to trac-dev

On Sun, Dec 15, 2013 at 4:30 AM, Christian Boos <christi...@free.fr> wrote:
[...] 
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.

fwiw ... few days ago I've requested to join the Spanish lang team @ transifex and would not mind to be the coordinator , if considered appropriate , I could also work towards the goal of becoming a committer ... btw, what are the steps to get there ?
 
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.

fwiw ... +1
 
[...]


--
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:


Brettschneider Falk

unread,
Dec 17, 2013, 8:57:36 AM12/17/13
to trac...@googlegroups.com
Hi,

A new Trac release would be very cool since I always have to update my server with an all-in-one Trac Stack package (Trac+Apache+SVN+Python), and I'm actually waiting for the chance to update from SVN 1.7 to 1.8. Though a new Bitnami release won't happen until Trac-1.0.2. :-) Furthermore, 104 bugfixes are waiting for the people... ;)

Remy Blank wrote:
> 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.
>
> Since we don't have a rigid release plan, whenever we feel that a branch is in
> a stable state is a good time for a release.

CU, F@lk

----
R&D Software
Baumer Optronic GmbH
www.baumer.com


Geschäftsführer: Dr. Albert Schmidt· Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE 189714583


RjOllos

unread,
Dec 17, 2013, 2:08:34 PM12/17/13
to trac...@googlegroups.com
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

RjOllos

unread,
Dec 19, 2013, 10:25:52 AM12/19/13
to trac...@googlegroups.com


On Sunday, December 15, 2013 1:30:58 AM UTC-8, cboos wrote:
[...]


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

I was going to create milestones for 0.12.7, 1.0.3 and 1.1.3 just now, but it seems that I don't have the MILESTONE_CREATE permission. 

Peter Suter

unread,
Dec 20, 2013, 12:59:54 PM12/20/13
to trac...@googlegroups.com
Hi


On 17.12.2013 20:08, RjOllos wrote:
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.

Unfortunately I will probably have zero time in the next couple of weeks for Trac. But please feel free to move my tickets to the next milestone and go ahead with the release as you see fit.

Thanks and Happy Holidays everyone

Peter

RjOllos

unread,
Dec 27, 2013, 8:44:24 AM12/27/13
to trac...@googlegroups.com
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.  

RjOllos

unread,
Dec 31, 2013, 11:14:13 PM12/31/13
to trac...@googlegroups.com
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,

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. 

RjOllos

unread,
Jan 1, 2014, 4:53:10 PM1/1/14
to trac...@googlegroups.com
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:


Presumably, changes in trac/locale should not be merged?

RjOllos

unread,
Jan 14, 2014, 7:37:26 PM1/14/14
to trac...@googlegroups.com

 
Presumably, changes in trac/locale should not be merged?

Will Green

unread,
Feb 13, 2014, 6:03:20 AM2/13/14
to trac...@googlegroups.com
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

Dirk Stöcker

unread,
Feb 13, 2014, 10:36:35 AM2/13/14
to trac...@googlegroups.com
Hello,

as you seem to have trouble with updating translations in Trac a comment
from my side.

For JOSM we're currently in the process of moving from Launchpad to
Transifex. For us this means we have a completely automated process to
update translations.

For JOSM we don't manage different release translations, but separate in
core, data and plugins. We have one big text space, split it into the
three parts and later join them again.

Means core: all in core
data: all in data except stuff already in core
plugins: all in plugins except stuff already in core and data

For Trac that could mean that main translation is trunk and the others
only contain strings, which are not already in the others.

The required task to do message extraction and joining are available as
"ant" task in JOSM repo (JOSM is Java, thus ant). But they aren't that
complicated. It is simply a set of msgmerge and similar commands.

Using this approach you can even have a nightly/weekly automated
translations update (for JOSM upload is weekly, download is still called
manual, but it is a single "ant update") and translators need to translate
each string only once.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Christian Boos

unread,
Feb 14, 2014, 6:31:55 PM2/14/14
to trac...@googlegroups.com
On 2014-02-13 4:36 PM, Dirk Stöcker wrote:
> Hello,
>
> as you seem to have trouble with updating translations in Trac a comment
> from my side.
>
> For JOSM we're currently in the process of moving from Launchpad to
> Transifex. For us this means we have a completely automated process to
> update translations.

Yes, having a somewhat automated and no-brainer process is the key.
So far, the manual procedure we have is too tedious.

> For JOSM we don't manage different release translations, but separate in
> core, data and plugins. We have one big text space, split it into the
> three parts and later join them again.

Having one big text space is also a key point for the simplicity.
However having different files for the different domains is not such a
big deal for us, and I think it even makes it easier for most
translators as not every translator will want to push as far as to
translate tracini.pot ;-)

I think it is rather having to juggle between the branch specific
catalogs which is the real issue for us, and a pain when it comes to
integrating the changes in the repository.

>
> Means core: all in core
> data: all in data except stuff already in core
> plugins: all in plugins except stuff already in core and data
>
> For Trac that could mean that main translation is trunk and the others
> only contain strings, which are not already in the others.

That could be one way, but I'm currently experimenting with a single
.pot file per domain (that is, tx-messages.pot, tx-messages-js.pot and
tx-tracini.pot), each containing the messages gathered from *all* the
branches (0.12-stable, 1.0-stable and trunk). These will be the only 3
resources (message catalog templates) pushed to Transifex. Once
translated, the corresponding message catalogs (i.e. the .po files for
all locales) will be pulled and split back into the different branches
according to the message IDs present in the .pot file for that branch.

If you would excuse my ASCII-art, the following diagrams illustrate the
new operating mode. I assume we start from a folder containing all the
different repositories.

$ ls
0.12-stable/ 1.0-stable/ trunk/

$ cd trunk
$ make merge-pots

| 0.12-stable/trac/locale/messages.pot ->-.
| 1.0-stable/trac/locale/messages.pot -->-|
| trunk/trac/locale/messages.pot ------->-|
| |
| trunk/trac/locale/tx-messages.pot <-----'

(that actually happens for messages-js.pot and tracini.pot as well)

$ tx push

(let the translators translate...)

$ tx pull

| trac/locale/fr/LC_MESSAGES/tx-messages.po

(and all the .po for the other locales and domains)

$ make unmerge-pos

| trunk/trac/locale/fr/LC_MESSAGES/tx-messages.po --->-.->-.->-.
| | | |
| 0.12-stable/trac/locale/messages.pot -------------->-| | |
| | | |
| 0.12-stable/trac/locale/fr/LC_MESSAGES/messages.po <-' | |
| | |
| 1.0-stable/trac/locale/messages.pot ------------------->-| |
| | |
| 1.0-stable/trac/locale/fr/LC_MESSAGES/messages.po <------' |
| |
| trunk/trac/locale/messages.pot ---------------------------->-|
| |
| trunk/trac/locale/fr/LC_MESSAGES/messages.po <---------------'

(that actually happens also for tx-messages-js.po and tx-tracini.po, but
also for all the locales)

>
> The required task to do message extraction and joining are available as
> "ant" task in JOSM repo (JOSM is Java, thus ant). But they aren't that
> complicated. It is simply a set of msgmerge and similar commands.

Likewise, the above merge/unmerge operations can easily be done with
Babel. I implemented it using Babel 0.9.6, but it should also work with
more recent versions.

>
> Using this approach you can even have a nightly/weekly automated
> translations update (for JOSM upload is weekly, download is still called
> manual, but it is a single "ant update") and translators need to
> translate each string only once.

We could indeed build on the above to automate things further, with a
few higher-level targets:
- tx-collect would do retrieve the translations and build them
(tx-pull, unmerge-pos, check-all, compile-all)
- tx-prepare would prepare and send the new messages to be translated
(extraction-all, merge-pots and tx-push)
- and finally tx-update would combine that (tx-collect, tx-prepare)

> Ciao

Thanks for the input!

To add some meat to the proposal, I've prepared the initial scripts and
added the merge-pots and unmerge-pos targets to the Makefile, in
http://trac.edgewall.org/changeset/167001b0/cboos.git but there's no
.tx/config change yet and nothing new on Transifex itself, yet.

I'd like to get some feedback about this approach first. Then the next
step would be to bootstrap the process and push the new resources and
catalogs (built from the existing translations) on Transifex. Once we
feel comfortable with that, we can remove the older resources.

-- Christian

Dirk Stöcker

unread,
Feb 15, 2014, 3:03:07 PM2/15/14
to trac...@googlegroups.com
On Sat, 15 Feb 2014, Christian Boos wrote:

> I'd like to get some feedback about this approach first. Then the next

For me it sounds like a good idea :-)

> step would be to bootstrap the process and push the new resources and
> catalogs (built from the existing translations) on Transifex. Once we
> feel comfortable with that, we can remove the older resources.

One P.S. I'd suggest to have a separate upload/download user for
transifex, so it is not tied to a user account.

Franz

unread,
Jun 27, 2014, 10:06:01 AM6/27/14
to trac...@googlegroups.com
Hi,

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?

Thanks in advance,
Franz

falkb

unread,
Jul 9, 2014, 3:54:37 AM7/9/14
to trac...@googlegroups.com


Am Sonntag, 15. Dezember 2013 10:30:58 UTC+1 schrieb cboos:
 
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.

What does "integration" mean here? What is actually to do? I'm actually a Qt programmer and there we have just .ts files for each language containing the translated texts (edit with Qt Linguist app by the translators), they are converted to a binary .qm file, and those .qm files are loaded by class QTranslator at runtime. What is the mechanism of Trac that got out of control?

CU, F@lk

RjOllos

unread,
Jul 14, 2014, 1:43:36 AM7/14/14
to trac...@googlegroups.com
On Friday, June 27, 2014 7:06:01 AM UTC-7, Franz wrote:
Hi,

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?

After the current batch of tickets is closed out in the next week or two we can make an attempt to put out a release.

The big question is whether one of the long-time Trac devs has time to do the release, or if one of us new devs should try to do the release by following:
For the latter we'll certainly need assistance since I'm sure we don't have permissions to publish the release in various places.

Christian Boos

unread,
Jul 16, 2014, 3:29:43 PM7/16/14
to trac...@googlegroups.com
What's got out of control is that the current workflow as described in
[1] is way too complicated. I could barely keep up when I was more
involved in Trac, now with some distance I see that it's flawed, we need
to simplify and automate more. The main flaw was that I assumed that
after some time, we'll have an active committer and a team coordinator
for each language (the group 1) and that hasn't happened and won't.

At this point, I think it's safer to assume that the translators will
prefer to work on Transifex, so that this should become our primary
source. We should have a mostly automated way to download everything
from there (synchronisation point), and commit the result, possibly
after the fixes done after checking the translations for
well-formedness. If such fixes are needed, we should then push them back
to Transifex (possibly overwriting edits done there since the
synchronisation point).

That's the rough picture. The other idea was to merge all the catalogs
for a language in a single one so that we avoid the problems related to
repeated work and with the merges [2].

I'll resume work on that soon, but that shouldn't hold on the imminent
release...

Speaking about that (0.12.6 / 1.0.2 / 1.1.2), I'm ready to give any
advice or even build the Windows parts, if needed. So Ryan, Jun and
Peter, don't hesitate to ask me if you need anything.
[2] - https://groups.google.com/d/msg/trac-dev/l5YuG7DysOE/cCyyjsiDBE8J

RjOllos

unread,
Jul 17, 2014, 1:06:14 AM7/17/14
to trac...@googlegroups.com

Thanks! It would be great to get a release out.

I currently have about a half dozen tickets in progress. What I'm thinking is:

 - Close out those tickets by Friday 07/25
 - Spend the next few days reviewing the tickets that were closed in the release, testing, trying to catch anything that may have been overlooked initially. String freeze on Monday 07/28.
 - Allow the two weeks for translators to update the catalogs.
 - Prepare the release on 08/08 or later.

How does that sound to the other devs?

Peter Suter

unread,
Jul 17, 2014, 2:11:08 AM7/17/14
to trac...@googlegroups.com
On 17.07.2014 07:06, RjOllos wrote:
> On Wednesday, July 16, 2014 12:29:43 PM UTC-7, cboos wrote:
> Speaking about that (0.12.6 / 1.0.2 / 1.1.2), I'm ready to give any
> advice or even build the Windows parts, if needed. So Ryan, Jun and
> Peter, don't hesitate to ask me if you need anything.
>

Maybe the main question is this:

On 14.07.2014 07:43, RjOllos wrote:
> For the latter we'll certainly need assistance since I'm sure we don't
> have permissions to publish the release in various places.

I.e. at the very end, how would we do the update steps in:
http://trac.edgewall.org/wiki/TracDev/ReleaseChecklist#Finalizetherelease

>
> Thanks! It would be great to get a release out.
>
> I currently have about a half dozen tickets in progress. What I'm
> thinking is:
>
> - Close out those tickets by Friday 07/25
> - Spend the next few days reviewing the tickets that were closed in
> the release, testing, trying to catch anything that may have been
> overlooked initially. String freeze on Monday 07/28.
> - Allow the two weeks for translators to update the catalogs.
> - Prepare the release on 08/08 or later.
>
> How does that sound to the other devs?

Sounds ok.

Though I think tickets should not hold up a release except in rare cases
(e.g. new bug in old functionality). Just move them to the next milestone.
At this point, late/no releases are more damaging to the project than
imperfect releases.

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**).

Saint Germain

unread,
Jul 17, 2014, 4:19:56 AM7/17/14
to trac...@googlegroups.com
On 17 July 2014 08:10, Peter Suter <pets...@gmail.com> wrote:
> On 17.07.2014 07:06, RjOllos wrote:
>> On Wednesday, July 16, 2014 12:29:43 PM UTC-7, cboos wrote:
>>> What's got out of control is that the current workflow as described in
>>> [1] is way too complicated. I could barely keep up when I was more
>>> involved in Trac, now with some distance I see that it's flawed, we need
>>> to simplify and automate more. The main flaw was that I assumed that
>>> after some time, we'll have an active committer and a team coordinator
>>> for each language (the group 1) and that hasn't happened and won't.
>>>
>>> At this point, I think it's safer to assume that the translators will
>>> prefer to work on Transifex, so that this should become our primary
>>> source. We should have a mostly automated way to download everything
>>> from there (synchronisation point), and commit the result, possibly
>>> after the fixes done after checking the translations for
>>> well-formedness. If such fixes are needed, we should then push them back
>>> to Transifex (possibly overwriting edits done there since the
>>> synchronisation point).
>>
>> I currently have about a half dozen tickets in progress. What I'm
>> thinking is:
>>
>> - Close out those tickets by Friday 07/25
>> - Spend the next few days reviewing the tickets that were closed in
>> the release, testing, trying to catch anything that may have been
>> overlooked initially. String freeze on Monday 07/28.
>> - Allow the two weeks for translators to update the catalogs.
>> - Prepare the release on 08/08 or later.
>>
>
> 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**).
>

Hello,

Speaking about translation, I am trying to help as much as possible
for the french part.
I participate to several other open source software translation and it
seems that everybody is moving to Transifex these days.
So I would vote to simplify the process and do everything in
Transifex. It would greatly simplify the work of the language team
coordinator (upload the changes, download the translation and commit).
If some people need to work outside Transifex, they can always
download/upload the .po file in Transifex.

Is there something wrong with this approach ?

Best regards,

Franz

unread,
Jul 17, 2014, 10:49:27 AM7/17/14
to trac...@googlegroups.com
We plan to write a Trac plugin handling translations. Currently our primary source are Java's resource bundles, but we also plan to support python's PO files. I just created a Trac-Hack [1] for this purpose. As this plugin will be subject of a Bachelor thesis and the Bachelor will start in October the implementation of the plugin has not yet begun. I had just wrote some considerations for this plugin at trac-hacks.

If you have any ideas or suggestions you are welcome to give your 5 cents ;-)

[1] http://trac-hacks.org/wiki/TranslationManagerPlugin

Best regards,
Franz

P.S.: I just requested to join the German language translation of the Trac project to get to know how Transifex works (and support Trac to be better translated).

Ryan Ollos

unread,
Jul 17, 2014, 12:10:16 PM7/17/14
to trac...@googlegroups.com


I need to commit a fix for a regression in #11610, and I think there is one other small issue, but I can't recall at the moment.

I can accelerate the timeline and wrap things up by this Saturday. That would give us the following timeline,

  1. Close out those tickets by Saturday 07/18
  2. Spend the next few days reviewing the tickets that were closed in

the release, testing, trying to catch anything that may have been
overlooked initially. String freeze on Monday 07/20.
  3. Allow the two weeks for translators to update the catalogs.
  4. Prepare the release on 08/01 or later.

I don't know the process well, so I can't comment on whether (3) can be sped up.

 
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 trac-dev+unsubscribe@googlegroups.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.

Peter Suter

unread,
Jul 17, 2014, 1:18:55 PM7/17/14
to trac...@googlegroups.com
On 17.07.2014 18:10, Ryan Ollos wrote:
> I need to commit a fix for a regression in #11610, and I think there is
> one other small issue, but I can't recall at the moment.
>
> I can accelerate the timeline and wrap things up by this Saturday.

I apologize, I didn't mean to rush you. A week or two more or less is of
course not going to be that important now. :)

(At least if Christian will still be available to assist by then.)

Ryan Ollos

unread,
Jul 17, 2014, 1:25:42 PM7/17/14
to trac...@googlegroups.com


No problem. You are right, the half dozen tickets in the milestone can be moved forward. So I'll just narrow the focus to the one or two tickets that are critical (fix for regressions) and we'll get this release out finally :)

Peter Suter

unread,
Jul 17, 2014, 2:05:24 PM7/17/14
to trac...@googlegroups.com
Hello

On 17.07.2014 10:19, Saint Germain wrote:
> So I would vote to simplify the process and do everything in
> Transifex. It would greatly simplify the work of the language team
> coordinator (upload the changes, download the translation and commit).
> If some people need to work outside Transifex, they can always
> download/upload the .po file in Transifex.
>
> Is there something wrong with this approach ?

I really don't know Transifex / translation processes well enough to
comment, but it sounds similar to what Christian proposed.

My main point is: If the process is nice for Trac translators but
impossibly complicated for releasing Trac, that doesn't help anyone.

If using Transifex exclusively simplifies the release process enough
then that's great of course.

RjOllos

unread,
Jul 25, 2014, 4:19:36 AM7/25/14
to trac...@googlegroups.com, ryan.j...@gmail.com


It seems I have let this drag on through the week. I'm currently 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.


RjOllos

unread,
Jul 26, 2014, 1:20:05 AM7/26/14
to trac...@googlegroups.com, ryan.j...@gmail.com


Christian, if you have a moment to take a look, there's a small change to MercurialPlugin that I'm unsure of:
http://trac.edgewall.org/ticket/11650#comment:7
It will be no problem to deal with the issue after the release if we can't immediately figure out if the change is okay. Since I'm not very familiar with the codebase and there's no unit test for MercurialPlugin I get extra nervous with making changes to that code.

Christian Boos

unread,
Jul 26, 2014, 5:14:26 AM7/26/14
to trac...@googlegroups.com
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 currently
> 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.

I'll be able to have some time on Sunday as well, maybe we could go
through the steps of creating some beta1 releases first.

> Christian, if you have a moment to take a look, there's a small change
> to MercurialPlugin that I'm unsure of:
> http://trac.edgewall.org/ticket/11650#comment:7
> It will be no problem to deal with the issue after the release if we
> can't immediately figure out if the change is okay. Since I'm not very
> familiar with the codebase and there's no unit test for MercurialPlugin
> I get extra nervous with making changes to that code.

At first glance the change seems OK to me. The behavior was there since
the early stages of the plugin, so maybe it was useful at one point
(maybe on Windows?). Anyway, I'll check.

-- Christian

Ryan Ollos

unread,
Jul 27, 2014, 2:55:33 PM7/27/14
to trac...@googlegroups.com
On Sat, Jul 26, 2014 at 2:14 AM, Christian Boos <christi...@free.fr> wrote:
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 currently
>     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.

I'll be able to have some time on Sunday as well, maybe we could go
through the steps of creating some beta1 releases first.

I'm available for the next 10 hours or so, currently pushing some final changes to the codebase and will start looking at the release process. I'll be on IRC.

Thanks for your help!

Ryan Ollos

unread,
Aug 4, 2014, 12:52:27 AM8/4/14
to trac...@googlegroups.com
Just wanted to send a quick update on progress. I have some more work to do updating the ChangeLog, and then a Wiki Page documentation sync (1). After that I think we can create a beta1. So possibly tomorrow.

If any other devs have some free time and want to work on the ApiChanges for 1.1.1 and 1.1.2, those pages will need more work (but I don't think that will hold up the release since the changes don't get sync'ed into the repository).

Please don't hesitate to correct any mistakes in the changes I've made to the wiki or tickets!

Samuel Degrande

unread,
Aug 4, 2014, 10:16:25 AM8/4/14
to trac...@googlegroups.com
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 !

--
Samuel Degrande LIFL - Universite de Lille 1
Phone: (33)3.62.53.15.70 IRCICA - Parc Scientifique de la Haute Borne
50 Av Halley - 59658 VILLENEUVE D'ASCQ - FRANCE

Ryan Ollos

unread,
Aug 14, 2014, 12:15:31 AM8/14/14
to trac...@googlegroups.com
On Mon, Aug 4, 2014 at 7:13 AM, Samuel Degrande <Samuel....@lifl.fr> wrote:
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 !

This is somewhat of a guess, but I would think that  /var/forge/projects/<that_project>/trac/plugins must be on sys.path. 

osimons

unread,
Aug 14, 2014, 2:49:11 AM8/14/14
to trac...@googlegroups.com

When you think about it, it really is the expected behaviour when running a forge in a single Python process (using a parent environment) and querying registries, setuptools and package tools to located named code. Once the plugin code loads into the process it will occupy that plugin name in the plugin registry across all projects, and Trac does not do any book-keeping to know from where the plugin originally loaded. We only use the location when iterating the plugins to see if it should be enabled. It won't be enough to use the same logic to filter the Plugin panel, as it will still be thrown off if the same plugin exists in two projects. What happens if you have two plugins with same name but at different versions? Trac cannot load/unload/reload Python code from a running proces.

There are a few lines about this in the documentation:

http://trac.edgewall.org/wiki/TracPlugins#Isthewrongversionofthepluginloading

Local plugins in a shared Python process is an illusion. Not surprisingly I've disabled the Plugins admin panel at CodeResort...


:::simon
https://www.coderesort.com

RjOllos

unread,
Aug 14, 2014, 8:40:44 PM8/14/14
to trac...@googlegroups.com, ryan.j...@gmail.com
Regarding documentation:

So far we have a single page for Trac 1.1:

On the other hand I have added some 1.1.x documentation directly to the guide:

Should we move the 1.1/TracTicketsCustomFields edits to TracTicketsCustomFields, or instead make a copy of all the documentation under 1.1 or 1.2 now and remove all mention of 1.1 from the Trac 1.0.x guide?

If we go with the former, should the 1.1-related stuff just get discarded in the sync when preparing the 1.0 documentation?: http://trac.edgewall.org/wiki/TracProject/DefaultWikiPages#sync

falkb

unread,
Aug 27, 2014, 4:55:33 AM8/27/14
to trac...@googlegroups.com

Hi,

What is the news with the release? Are you stuck again somewhere? How can I help?

CU, F@lk


Ryan Ollos

unread,
Aug 27, 2014, 5:01:25 AM8/27/14
to trac...@googlegroups.com
Just need to confirm that the installation steps are correct when using setuptools 5.4 - 5.6, and taking into consideration the warnings we added to the docs and the patch that will soon be committed,
http://trac.edgewall.org/ticket/11694#comment:20

Unfortunately I'm very busy at my day job until Friday, so not sure if I will find time before this weekend.

RjOllos

unread,
Sep 7, 2014, 3:25:57 PM9/7/14
to trac...@googlegroups.com, ryan.j...@gmail.com
Sorry for the continued delays. I'm not having success authenticating with the edgewall server at the moment, so I've dropped the files into my dropbox account and made them public:


These are just for "beta1" release testing. So far I've only done a smoke test of the install on Linux, but I'll be doing more testing later today.


RjOllos

unread,
Sep 16, 2014, 11:41:59 AM9/16/14
to trac...@googlegroups.com, ryan.j...@gmail.com

falkb

unread,
Sep 17, 2014, 2:05:07 AM9/17/14
to trac...@googlegroups.com, ryan.j...@gmail.com
Hi!


Am Dienstag, 16. September 2014 17:41:59 UTC+2 schrieb RjOllos:
The latest beta1 packages are available on the Downloads site (1):

Great news!! I'm going to give it a shot on Win7.
 

There seems to be a question as to whether the installer for the win64 platform is neeeded (2).

I would suggest to completely leave this part to the Bitnami guys who are doing a great packaging job.

CU, F@lk

falkb

unread,
Sep 19, 2014, 2:35:15 PM9/19/14
to trac...@googlegroups.com, ryan.j...@gmail.com
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

Ryan Ollos

unread,
Sep 23, 2014, 6:28:17 AM9/23/14
to Brettschneider Falk, trac...@googlegroups.com


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
> <http://www.google.com/url?q=http%3A%2F%2Fdownload.edgewall.org%2Ftrac%2FTrac-1.0.2beta1.win32.exe&sa=D&sntz=1&usg=AFQjCNFH_0dekgL-vUO6PwI3G0XPxz3qNA>

> 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

falkb

unread,
Oct 6, 2014, 3:01:42 AM10/6/14
to trac...@googlegroups.com, fbretts...@baumer.com, ryan.j...@gmail.com
Hi,
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.
CU, F@lk

Ryan Ollos

unread,
Oct 6, 2014, 7:43:43 AM10/6/14
to falkb, trac...@googlegroups.com
On Mon, Oct 6, 2014 at 12:01 AM, falkb <fbretts...@baumer.com> wrote:

Hi,
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.
CU, F@lk

I've been traveling for a few weeks so I haven't had access to a Windows development machine to do any testing myself. I haven't heard from anyone other than you about testing the installers. I'll be home on Thursday and will do some testing at that time.

If you'd like to try creating the dist packages again or further debugging the issue you experienced, the steps for creating the dist packages can be found here:
http://trac.edgewall.org/wiki/TracDev/ReleaseChecklist#Createdistpackages

falkb

unread,
Oct 6, 2014, 11:19:55 AM10/6/14
to trac...@googlegroups.com, ryan.j...@gmail.com
Do you know if amd-64bit is only for the AMD CPU or is it for all 64bit CPUs?
CU, F@lk

Peter Suter

unread,
Oct 6, 2014, 3:14:00 PM10/6/14
to trac...@googlegroups.com
On 06.10.2014 17:19, falkb wrote:
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. (It's just an old / alternative name of x86-64, which was designed by AMD but implemented by AMD, Intel and others.)
http://en.wikipedia.org/wiki/X86-64

You need that one if you have the x86-64 version of Python, or it won't work.
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.


falkb

unread,
Oct 7, 2014, 4:04:14 AM10/7/14
to trac...@googlegroups.com
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. Thanks.

CU, F@lk

falkb

unread,
Oct 7, 2014, 4:08:40 AM10/7/14
to trac...@googlegroups.com


Am Montag, 6. Oktober 2014 21:14:00 UTC+2 schrieb Peter Suter:

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.


Did you install with Admin permissions? Did you install with a previously installed Trac installation or on a clean machine?

CU, F@lk

Ryan Ollos

unread,
Oct 7, 2014, 5:41:39 AM10/7/14
to trac...@googlegroups.com
On Tue, Oct 7, 2014 at 1:04 AM, falkb <fbretts...@baumer.com> wrote:
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.

win32 and amd64 are the suffixes generated by setuptools, but we could change the latter to win64, or use x86 and x64.
 
As the installer didn't work here, I suspected the reason is that it is designed for AMD CPUs, only.

No, it is just convention like Peter mentioned and as described in the article he referenced.

Christopher Nelson

unread,
Oct 23, 2014, 9:42:07 PM10/23/14
to trac...@googlegroups.com
On Tue, Sep 16, 2014 at 11:41 AM, RjOllos <rjo...@gmail.com> wrote:
> On Sunday, September 7, 2014 12:25:57 PM UTC-7, RjOllos wrote:
>> On Wednesday, August 27, 2014 2:01:25 AM UTC-7, RjOllos wrote:
>>> On Wed, Aug 27, 2014 at 1:55 AM, falkb <fbretts...@baumer.com>
>>> wrote:
>...
> 1.0.2beta1:
> http://download.edgewall.org/trac/Trac-1.0.2beta1.tar.gz
>> ...

Installed on Ubuntu 12.04 and fired up tracd. Very quick smoke test
but that much works.

RjOllos

unread,
Oct 23, 2014, 11:23:43 PM10/23/14
to trac...@googlegroups.com
I did some testing and found the same as you. The win32 version of Trac will only detect a win32 install of Python in the registry, and similarly for the win-amd64 versions.

The win32 package seems to be created correctly from a win-amd64 install of Python. This is surprising from what I read in the documentation, but the documentation is not overly detailed:

 

Jun Omae

unread,
Oct 23, 2014, 11:36:32 PM10/23/14
to trac...@googlegroups.com
On Fri, Oct 24, 2014 at 12:23 PM, RjOllos <rjo...@gmail.com> wrote:
> The win32 package seems to be created correctly from a win-amd64 install of
> Python. This is surprising from what I read in the documentation, but the
> documentation is not overly detailed:
> https://docs.python.org/2/distutils/builtdist.html#cross-compiling-on-windows

I guess bdist_wininst command with --plat-name option doesn't work for
executable launcher as expected.

bdist_wininst --plat-name=win-amd64 on win32 environment generates
executable launcher using cli-32.exe. I think that behavior is a
defect.

I've reported it in https://bitbucket.org/pypa/setuptools/issue/253.

--
Jun Omae <jun...@gmail.com> (大前 潤)

RjOllos

unread,
Oct 24, 2014, 2:23:53 AM10/24/14
to trac...@googlegroups.com
I've built the win32 and win-amd64 packages on the corresponding version of Python to avoid potential issues.

The Python packages use "win-amd64" in the name and the convention seems to be fairly well known, even if it is confusing, so I chose not to overthink this and rename them, at least for now. If there's consensus that we should use a pattern such as win32 / win64 or x86 / x64, then we can do that in the next release. I'd also like to understand if there are advantages to providing MSI installers rather than EXE installers, like Python does:

The packages are up on PyPI now (but hidden) and on the Trac downloads site (but not linked from the wiki):



I'm out of time this evening. After I finish smoke-testing all of the installers tomorrow morning I'll move forward with making the release public. Please let me know if you spot any issues before then.

falkb

unread,
Oct 24, 2014, 3:05:21 AM10/24/14
to trac...@googlegroups.com
Hi,
The AMD-naming for now is fine with me. It's just increases confusion and leads to a wrong suspicion in case something goes wrong with the installation.
I'm going to test again this evening CET...
CU, F@lk

RjOllos

unread,
Oct 24, 2014, 1:33:47 PM10/24/14
to trac...@googlegroups.com
The releases are available on the TracDownload page and on PyPI. Announcement email forthcoming in a few hours.

falkb

unread,
Oct 24, 2014, 5:57:46 PM10/24/14
to trac...@googlegroups.com
Hi,

Am Freitag, 24. Oktober 2014 19:33:47 UTC+2 schrieb RjOllos:
> http://trac.edgewall.org/wiki/TracDownload

I've tested the amd-64 one, and the result on my 64bit Windows 7 is a FAIL: After the first click on the "Next" button an error message appears saying "No python installation found in the registry". After clicking OK, only "Back" and "Abort" buttons are active.
I've tested also the 32-bit one on my 64bit Windows 7 and it's a FAIL as well: It is able to detect my Python-7 installation via registry in C:\Program Files\BitNamiTrac-1.0/python\Lib\site-packages\ but clicking the "Next" button two times crashes the installer application.

CU, F@lk

Ryan Ollos

unread,
Oct 24, 2014, 6:47:23 PM10/24/14