Just a heads up that I updated t.e.o to Trac 0.11dev-r6870 and Genshi
0.5dev-r845.
/ Jonas
Is it any better memory-wise?
I still plan to have a look at the .csv issue with reports, but that's
about it for #6614.
After the #216 integration, I think we can prepare a 0.11rc1 (end of
this week?), and release 0.11 itself once Genshi 0.5 is out (any news on
that?)
-- Christian
I have to wait until cmlenz is back from his 3 week holiday to roll up 0.5
including Windows eggs and the likes. That's ~2.5 weeks from now. So I hope
to have Genshi 0.5 out half May or the week after that.
Think we can release Trac 0.11 at the end of May?
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Any road leads to the end of the world...
I think we can get a 0.11rc1 quite soon, then I'd said we can branch
0.11-stable and later we'll release 0.11 from that.
We've been in feature freeze on trunk for long enough now and the
feature branches begin to pile up, so I'd like to move forward and get
them on trunk before more serious work for 0.12 begins.
For next week, I'll write a more detailed proposal about what we should
do for 0.12, both for Trac itself and for the way we develop it.
OTOH, there's a huge pile of outstanding issues waiting in the 0.11.1
area (most prominent one being #3563), so we can find plenty things to
do on branches/0.11-stable, while waiting for end of May...
-- Christian
It seems you didn't update the htdocs:
http://www.edgewall.org/chrome/common11/js/diff.js corresponds to the
version before the fixed one (r6853).
-- Christian
> 0.5dev-r845.
>
> / Jonas
>
> >
>
>
Sounds fine by me. +1.
>For next week, I'll write a more detailed proposal about what we should
>do for 0.12, both for Trac itself and for the way we develop it.
Sounds interesting, looking forward to it.
>OTOH, there's a huge pile of outstanding issues waiting in the 0.11.1
>area (most prominent one being #3563), so we can find plenty things to
>do on branches/0.11-stable, while waiting for end of May...
Right now the unittests for Python 2.3 fail for Trac. Part is due to
subprocess being imported, which is non-existent for 2.3.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
But the time has come when all good things shall pass...
See Trac-users of this morning, for hints ;-)
>
>> OTOH, there's a huge pile of outstanding issues waiting in the 0.11.1
>> area (most prominent one being #3563), so we can find plenty things to
>> do on branches/0.11-stable, while waiting for end of May...
>>
>
> Right now the unittests for Python 2.3 fail for Trac. Part is due to
> subprocess being imported, which is non-existent for 2.3.
>
That's for the functional tests. Well, those tests should simply be
disabled when the appropriate supporting modules are not there (i.e. the
same way it goes when twill is not present). On a related note, I wonder
if we should continue support for 2.3, with so many newer Python
releases out there (2.4 and 2.5 available for years, 2.6 coming soon,
and 3.0 on the distant horizon). Given the memory issues with Genshi, I
wouldn't even advise running Trac with Python 2.4. We can keep Python
2.3 compatibility on 0.11-stable, but we can now think about using 2.4
or even 2.5 features for upcoming versions.
-- Christian
Genshi 0.5 will support 2.3, as such 0.11 should also do so. With 0.12 I
expect us to release when 2.6 has been released and 2.3 can be dropped. I
remember Christopher saying 2.3 support for Genshi will go after Genshi 0.5
has been released.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Knowledge speaks, but wisdom listens...
Are you sure it isn't some kind of browser cache issue?
$ curl http://www.edgewall.org/chrome/common11/js/diff.js | md5
d881ecc9a057c9f8a969c3978e879567
$ curl http://svn.edgewall.org/repos/trac/trunk/trac/htdocs/js/diff.js |
md5
d881ecc9a057c9f8a969c3978e879567
This morning I removed a trac restart script from the t.e.o crontab and
so far the memory usage seems to be fairly stable without it, but I'll
continue monitoring it:
http://www.edgewall.org/rrd/mem-day.png
Regarding having a rc1 release in the next couple of days I'm also +1. A
release this Sunday would work best for me personally. But if anyone
need some more time to finish something that should go into rc1 we can
always pick another date.
/ Jonas
I'm ok with it too.
Only thing I cannot do right now is get a Genshi 0.5 rc1 out of the door
without cmlenz around.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
I dream of gardens in the desert sand...
I haven't had time to work on http://trac.edgewall.org/ticket/6879 . I think
it's going to be a significant issue for some, and I'm afraid it's going to
be a bit of work to fix correctly. I also think we do need to change it,
rather than leave it as-is as cboos suggested; the users expect it to behave
in the same basic way as it did in 0.10, and I think they're right.
Whether this is something that blocks an rc1 or not is left open for
discussion.
Eli
------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
retr...@gmail.com `-------------------------------------------------
Indeed, it was a cache issue in Firefox - I thought I did a force
reload, but probably didn't. I'm not sure why this explicit reload is
needed at all (Firefox bug? server setup?).
> This morning I removed a trac restart script from the t.e.o crontab and
> so far the memory usage seems to be fairly stable without it, but I'll
> continue monitoring it:
>
> http://www.edgewall.org/rrd/mem-day.png
>
Interesting, so what exactly happened near 6:20 AM this morning?
(I guess that what happened at 09:40 AM was a server restart ;-) ).
> Regarding having a rc1 release in the next couple of days I'm also +1. A
> release this Sunday would work best for me personally. But if anyone
> need some more time to finish something that should go into rc1 we can
> always pick another date.
>
Sunday will be good for me too. We shouldn't make a big deal of this
rc1, as like Jeroen said, we need to wait for the release of Genshi 0.5
before releasing 0.11 itself. So this will give us some time for a
couple of rc, if needed.
-- Christian
Probably a browser issue since the server doesn't send any Expires
headers at all, just normal Last-Modified and Etag headers. Are you
perhaps behind some kind of (transparent) http proxy?
>> This morning I removed a trac restart script from the t.e.o crontab and
>> so far the memory usage seems to be fairly stable without it, but I'll
>> continue monitoring it:
>>
>> http://www.edgewall.org/rrd/mem-day.png
>
> Interesting, so what exactly happened near 6:20 AM this morning?
> (I guess that what happened at 09:40 AM was a server restart ;-) ).
Yeah, it took a while to figure out what happend at 6:25 but then I
realized that that's the exact time the daily crontab jobs are started.
The spike in memory allocation was caused by logrotate restarting
lighttpd in a way that didn't manage to kill all running fastcgi
processes before starting a new set of processes. This should be fixed
now so tomorrow at the same time we should see a drop in memory usage
instead of an increase.
/ Jonas
> Jeroen Ruigrok van der Werven wrote:
>> -On [20080422 20:48], Christian Boos (cb...@neuf.fr) wrote:
>>
>>> I think we can get a 0.11rc1 quite soon, then I'd said we can branch
>>> 0.11-stable and later we'll release 0.11 from that.
>>>
>>
>> Sounds fine by me. +1.
>>
>>
>>> For next week, I'll write a more detailed proposal about what we should
>>> do for 0.12, both for Trac itself and for the way we develop it.
>>>
>>
>> Sounds interesting, looking forward to it.
>>
>
> See Trac-users of this morning, for hints ;-)
Hi Christian,
I don't see any threads beginning around that time from you. Do you
have a more specific pointer?
Thanks,
--
Dave Abrahams
Boost Consulting
http://boost-consulting.com
See http://groups.google.com/group/trac-users/msg/eed510f50f82c109
-- Christian
Jonas, I'm really sorry, I couldn't find the time this week-end to even
show up on #trac or send a mail.
What about doing the last bunch of changes beginning of this week, test
it during the second part of the week, and if all goes well, release
next week? (again, if time permits...)
Besides, I wonder if we shouldn't take the opportunity of this 0.11rc1
release to also make a 0.10.5 release (with mostly the current status of
0.10.5dev) and officially "freeze" the 0.10.x branch. There are a couple
of important bug fixes in 0.10.5 (1), so that leaving 0.10.4 as the last
stable release for that development line doesn't feel optimal. Could
people running 0.10.5dev comment about the stability?
The only thing that should probably be added to 0.10.5dev is the
backport of r6240 (2), so that base_url would behave uniformly in
0.10.4, 0.10.5 and 0.11, with the base_url_for_redirect option present
in 0.10.5 and 0.11. Trac 0.10.4 would still have the issue of reverting
to http when https in some cases (see e.g. #5454).
-- Christian
PS: I'm also sorry for r6893 - well, at least my mistake helped to catch
the problem with the log handler...
[1] -
http://trac.edgewall.org/log/branches/0.10-stable?rev=6852&stop_rev=5235
[2] - http://trac.edgewall.org/changeset/6240
Noah was quite against putting out a rc without a deploy target in it for
the *gi-bin and htdocs stuff.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
My name is Legion: for we are many...
No problem Christian, there was still the "script deploy" thing that
needed to be addressed first. But now with that in place I can see a rc1
release tomorrow unless there are more release blockers I don't know
about.
/ Jonas
Its done, trac-admin ... deploy.
--Noah
Thanks!
Well, I don't have blockers, strictly speaking, but as the changes I
would like to make for rc1 (merge of the #216 branch, next_rev
optimization, ...) present as always the risk of introducing some new
issues, so I'd prefer that we let a few days pass on t.e.o once it's
running (successfully) at the latest revision.
I've committed a bunch of those this evening, and perhaps a few more
tomorrow (#3563, #7105).
-- Christian
t.e.o has been running r6904 since last night and was just updated to
r6906.
Anyone planning to commit any more non-trivial code changes or can we
freeze trunk now and try to release rc1 later today?
/ Jonas
I just committed fixes for #7105 and #7168.
Now, I see that you're eager to release, so I'll stop here ;-)
Please also have a look at fixing #3674 locally on t.e.o, by applying
the fix described in http://trac.edgewall.org/ticket/3674#comment:21
-- Christian
I'm clear. Let me sync to trunk now for my branches as well.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Weep for the lives your wishes never lead...
Of course it would be nice to get rc1 out the door. We can always
postpone some minor bug-fixes until rc2 or 0.11final at we need to
include all tickets which affects the api into rc1. And there is still
#6879 which Eli is working on which I forgot.
> Please also have a look at fixing #3674 locally on t.e.o, by applying
> the fix described in http://trac.edgewall.org/ticket/3674#comment:21
I'll have a look at it.
/ Jonas
Sorry to be the one holding up the release. :(
I committed a minimal fix for #6879 in r6919. It does open up another issue,
which I filed as #7176. But I think that issue is lower priority... it's a
custom-workfow-action-plugin + user-interface gotcha. It is something that
needs to be fixed, but it's going to take a bit of work, and I don't think
it's a release blocker.