Project should use it's own results (0.11dev should be on t.e.o)

[ilias@…]

This would have some benefits, e.g. that developers have to take more care and that issues like #4174 will become available 'naturally'.

This could be combined with a log of 'healthy revisions', where 'good-revisions' are noted, thus users can check-out the latest 'good-revision'.

[Emmanuel Blot]

See #4163

[ilias@…]

Replying to eblot:

See #4163

I meant really the version used, not test-instances.

t.e.o → 0.11dev

[Christian Boos]

This is what we always do… there will be a time before the 0.11 release when 0.11dev will be installed and used on t.e.o.

(getting the ticket out of the {20} list)

[Christian Boos]

… that time is getting nearer ;-)

Still need to fix #5025 first.

[ilias@…]

see ​topic subjecting an unsuccessful switch to 0.11

[Christian Boos]

Jonas on Trac-dev:

t.e.o has now been running trunk for the last 3-4 hours. The memory 
usage is still a lot higher than 0.10 but seems to be much more stable 
than our last attempt. One fastcgi process has currently allocated 276MB 
resident memory. That is a lot more than 0.10.x (Around 120MB) but it 
seems to have stabilized at that level for the moment.

Some details:
Trac r6669.
Genshi r801.
Python 2.4.3 (x86_64)

And please, no need to create similar ticket for future versions of Trac. Our policy is to run the stable branch of a given major version after it has been made, until the next major version is close enough to be released itself (beta1 stage).

[ilias@…]

Replying to cboos: …

Our policy is to run the stable branch of a given major version after it has been made, until the next major version is close enough to be released itself (beta1 stage).

And exactly this policy is not very efficient. you should trust yourself more, and run the actual trunk (in conjunction with a "healthy-version-log")