Trac 0.12.6 / 1.0.2 / 1.1.2

[RjOllos]

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]

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

[Christian Boos]

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]

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]

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]

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]

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]

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]

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]

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. 

[RjOllos]

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?

[RjOllos]

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 

[Will Green]

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]

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]

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]

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]

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]

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]

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:

http://trac.edgewall.org/wiki/TracDev

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]

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.

-- Christian

[1] - http://trac.edgewall.org/wiki/TracL10N/Transifex

[2] - https://groups.google.com/d/msg/trac-dev/l5YuG7DysOE/cCyyjsiDBE8J

[RjOllos]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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!

http://trac.edgewall.org/wiki/TracProject/DefaultWikiPages#sync

[Samuel Degrande]

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]

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]

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]

Regarding documentation:

So far we have a single page for Trac 1.1:

http://trac.edgewall.org/wiki/1.1/TracTicketsCustomFields

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

http://trac.edgewall.org/wiki/TracReports?action=diff&version=53

http://trac.edgewall.org/wiki/TracTicketsCustomFields?action=diff&version=2

http://trac.edgewall.org/wiki/TracUpgrade?action=diff&version=96

http://trac.edgewall.org/wiki/TracWorkflow?action=diff&version=50&old_version=47

http://trac.edgewall.org/wiki/WikiProcessors?action=diff&version=62&old_version=60

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]

Hi,

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

CU, F@lk

[Ryan Ollos]

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]

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:

https://www.dropbox.com/sh/hssna7r01jscboh/AAA9Yehxd_uAYU4CdNpd_Hooa?dl=0

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]

The latest beta1 packages are available on the Downloads site (1):

0.12.6beta1:
http://download.edgewall.org/trac/Trac-0.12.6beta1.tar.gz
http://download.edgewall.org/trac/Trac-0.12.6beta1.win-amd64.exe
http://download.edgewall.org/trac/Trac-0.12.6beta1.win32.exe
http://download.edgewall.org/trac/Trac-0.12.6beta1.zip
 
1.0.2beta1:
http://download.edgewall.org/trac/Trac-1.0.2beta1.tar.gz
http://download.edgewall.org/trac/Trac-1.0.2beta1.win-amd64.exe
http://download.edgewall.org/trac/Trac-1.0.2beta1.win32.exe
http://download.edgewall.org/trac/Trac-1.0.2beta1.zip

1.1.2beta1:
http://download.edgewall.org/trac/Trac-1.1.2beta1.tar.gz
http://download.edgewall.org/trac/Trac-1.1.2beta1.win-amd64.exe
http://download.edgewall.org/trac/Trac-1.1.2beta1.win32.exe
http://download.edgewall.org/trac/Trac-1.1.2beta1.zip

Please let us know if you have an opportunity to test the packages. I can test on Ubuntu 14.04 and maybe Windows 8, but I won't have any time until at least this weekend.

There seems to be a question as to whether the installer for the win64 platform is neeeded (2). I also noticed that setuptools can create MSI packages, but I'm not sure if those are needed, preferred by some, in addition to EXEs.

(1) http://download.edgewall.org/trac/
(2) http://trac.edgewall.org/ticket/11694#comment:31

[falkb]

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]

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]

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]

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]

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]

Do you know if amd-64bit is only for the AMD CPU or is it for all 64bit CPUs?
CU, F@lk

[Peter Suter]

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]

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]

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]

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]

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]

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:

https://docs.python.org/2/distutils/builtdist.html#cross-compiling-on-windows

 

[Jun Omae]

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]

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:

https://www.python.org/downloads/release/python-278/

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

https://pypi.python.org/pypi/Trac/1.0.2

https://pypi.python.org/pypi/Trac/0.12.6

http://download.edgewall.org/trac/Trac-0.12.6.tar.gz

http://download.edgewall.org/trac/Trac-0.12.6.zip

http://download.edgewall.org/trac/Trac-0.12.6.win-amd64.exe

http://download.edgewall.org/trac/Trac-0.12.6.win32.exe

http://download.edgewall.org/trac/Trac-1.0.2.tar.gz

http://download.edgewall.org/trac/Trac-1.0.2.zip

http://download.edgewall.org/trac/Trac-1.0.2.win-amd64.exe

http://download.edgewall.org/trac/Trac-1.0.2.win32.exe

http://download.edgewall.org/trac/Trac-1.1.2.tar.gz

http://download.edgewall.org/trac/Trac-1.1.2.zip

http://download.edgewall.org/trac/Trac-1.1.2.win-amd64.exe

http://download.edgewall.org/trac/Trac-1.1.2.win32.exe

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]

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]

The releases are available on the TracDownload page and on PyPI. Announcement email forthcoming in a few hours.

http://trac.edgewall.org/wiki/TracDownload 

[falkb]

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]

On Fri, Oct 24, 2014 at 3:46 PM, Ryan Ollos <ryan.j...@gmail.com> wrote:

I don't know why it detected that location as the root of a Python installation. C:\Program Files\BitNamiTrac-1.0/python might be correct, or perhaps you misquoted that and it's actually the installation location:





The 32-bit Trac package goes with the 32-bit Python package, and similarly for the 64-bit version. It sounds like the only version of Python you have installed is the one that came with your Bitnami installation. You should install a standard Python package for your platform (e.g. C:\Python27), either 32-bit or 64-bit (doesn't matter which you choose), but just make sure to use the matching Trac installer for the Python package:
https://www.python.org/downloads

[RjOllos]

Christian spotted an error with the win32 package. It looks like I missed a step and the locale directory didn't get included in the package. There will probably be a revision to that package before the release is announced, but not sure how we are going to handle the naming of the package yet. 

[Dirk Stöcker]

On Fri, 24 Oct 2014, RjOllos wrote:

> The releases are available on the TracDownload page and on PyPI. Announcement email forthcoming in a few hours.

I'd prefer when the source releases e.g. used by easy_install don't have
"\r\n" as line endings and use "\n" instead. It's pretty ugly on Unix
systems.

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

[Ryan Ollos]

On Fri, Oct 24, 2014 at 12:25 PM, Dirk Stöcker <tr...@dstoecker.de> wrote:

On Fri, 24 Oct 2014, RjOllos wrote:

The releases are available on the TracDownload page and on PyPI. Announcement email forthcoming in a few hours.

I'd prefer when the source releases e.g. used by easy_install don't have "\r\n" as line endings and use "\n" instead. It's pretty ugly on Unix systems.

Ciao

The tar.gz release should have "\n" line endings. The zip release should have "\r\n". So just easy_install using the tar.gz release on Unix.

[Jun Omae]

The easy_install prefers zip archive even if Unix if both tar.gz and
zip archives exist, like this.

$ virtualenv /dev/shm/trac-1.0.2
...
$ /dev/shm/trac-1.0.2/bin/easy_install Genshi
...
$ /dev/shm/trac-1.0.2/bin/easy_install Trac
Searching for Trac
Reading http://pypi.python.org/simple/Trac/
Reading http://projects.edgewall.com/trac
Reading http://projects.edgewall.com/trac/wiki/TracDownload
Reading http://trac.edgewall.com/
Best match: Trac 1.0.2
Downloading https://pypi.python.org/packages/source/T/Trac/Trac-1.0.2.zip#md5=4729d7dfa9cb4f12063f001e7d753204
Processing Trac-1.0.2.zip
Running Trac-1.0.2/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-xUDOB3/Trac-1.0.2/egg-dist-tmp-b4Kba8
Adding Trac 1.0.2 to easy-install.pth file
Installing trac-admin script to /dev/shm/trac-1.0.2/bin
Installing tracd script to /dev/shm/trac-1.0.2/bin

Installed /run/shm/trac-1.0.2/lib/python2.7/site-packages/Trac-1.0.2-py2.7.egg
Processing dependencies for Trac
Finished processing dependencies for Trac

[Ryan Ollos]

On Sat, Oct 25, 2014 at 1:00 AM, Jun Omae <jun...@gmail.com> wrote:

On Sat, Oct 25, 2014 at 4:46 PM, Ryan Ollos <rjo...@gmail.com> wrote:
> On Fri, Oct 24, 2014 at 12:25 PM, Dirk Stöcker <tr...@dstoecker.de> wrote:
>>
>> On Fri, 24 Oct 2014, RjOllos wrote:
>>
>>> The releases are available on the TracDownload page and on PyPI.
>>> Announcement email forthcoming in a few hours.
>>
>>
>> I'd prefer when the source releases e.g. used by easy_install don't have
>> "\r\n" as line endings and use "\n" instead. It's pretty ugly on Unix
>> systems.
>>
>> Ciao
>
>
> The tar.gz release should have "\n" line endings. The zip release should
> have "\r\n". So just easy_install using the tar.gz release on Unix.

The easy_install prefers zip archive even if Unix if both tar.gz and
zip archives exist, like this.

The case willneed to be made why we should favor one particular set of line endings. Supposing "\r\n" causes problems on Unix (I don't know, I've never noticed any problems), does "\n" not cause any problems on Windows?

[Dirk Stöcker]

On Sat, 25 Oct 2014, Ryan Ollos wrote:

> The case willneed to be made why we should favor one particular set of
> line endings.

Because "\n" is the standard for all operating systems with only one
exception. And it is BTW also the way how the files are stored in the
versioning system.

> Supposing "\r\n" causes problems on Unix (I don't know, I've never
> noticed any problems), does "\n" not cause any problems on Windows?

Neither does \r\n cause major problems under Linux, nor does \n cause
problems for Windows.

But e.g. you will get conversion issues for any patches from Unix users
and if somebody uses the release files and copies these into SVN results
will be \r\n checkins for UNIX SVNs, diffs and patch files don't work
without conversion first, ...

As said. It is simply UGLY and non-standard.

[Jun Omae]

No problems in Python files. But "\r\n" in Genshi email templates
leads problems on Unix with Genshi 0.6.1/0.7.0, see
http://trac-hacks.org/ticket/11159.

As far as I know, "\n" doesn't lead any problems on Windows.

[falkb]

I have a common valid installation of Bitnami Trac 1.0.1-1 which uses Python 2.7.3. It's installed in C:\Program Files\BitNamiTrac-1.0 (default path). I think Bitnami uses a standard Python.
Your new installer shows these errors for the 64bit (Python not found) and 32bit version (crash). Maybe that Bitnami Trac is a 32bit one on my 64bit machine but I haven't had problems with that, that works well.

CU, F@lk

Am Samstag, 25. Oktober 2014 00:47:23 UTC+2 schrieb RjOllos:
> I don't know why it detected that location as the root of a Python installation. C:\Program Files\BitNamiTrac-1.0/python might be correct, or perhaps you misquoted that and it's actually the installation location:

[RjOllos]

Thanks for the info. The zip package has always been created on Windows (at least that is what the release steps dictate: http://trac.edgewall.org/wiki/TracDev/ReleaseChecklist#Createdistpackages), but we can consider changing that for the 0.12.7/1.0.3/1.1.3 releases.

 

[Peter Suter]

On 25.10.2014 23:51, falkb wrote:
> I have a common valid installation of Bitnami Trac 1.0.1-1 which uses
> Python 2.7.3. It's installed in C:\Program Files\BitNamiTrac-1.0
> (default path). I think Bitnami uses a standard Python.
> Your new installer shows these errors for the 64bit (Python not found)
> and 32bit version (crash). Maybe that Bitnami Trac is a 32bit one on my
> 64bit machine but I haven't had problems with that, that works well.

I just installed Bitnami Trac 1.0.1-4 (1.0.1-1 doesn't seem to be
available anymore) and then the Trac 1.0.2 win32 installer without a
problem.

Bitnami indeed bundles a 32bit Python. So "Python not found" for the
64bit installer is to be expected.

Maybe you can try upgrading to Bitnami 1.0.1-4 first?

[Peter Suter]

On 24.10.2014 08:23, RjOllos wrote:
> in the next release. I'd also like to understand if there
> are advantages to providing MSI installers rather than EXE installers

I don't know exactly the tradeoffs, but stumbled on an old mail [1] that
lists some.

Another advantage for debugging problems may be that MSI installers can
enable logging [2]:
msiexec /l*v "log.log" /i "trac.msi"
(Although it is maybe very rare that this is needed or helps much.)
Or do the EXE installers have something similar?

[1] https://mail.python.org/pipermail/distutils-sig/2007-July/007811.html
[2] http://msdn.microsoft.com/en-us/library/aa367988%28v=vs.85%29.aspx

[Peter Suter]

On 07.10.2014 10:08, falkb wrote:
> Did you install with Admin permissions? Did you install with a
> previously installed Trac installation or on a clean machine?

I don't think I ever needed any Admin permissions, but all my Python
installations (including the one by Bitnami) were outside "C:\Program
Files". You may need Admin rights to install there.

Perhaps the --user-access-control option [1] should be set when building
the installer?

[1]
https://docs.python.org/2/distutils/builtdist.html#vista-user-access-control-uac

[Peter Suter]

See
http://bugs.python.org/issue16561

[RjOllos]

Thanks for the info. I added a TODO to the release checklist to evaluate the option in the next release.
http://trac.edgewall.org/wiki/TracDev/ReleaseChecklist?version=44