Trac 0.11beta1 coming soon
Christian Boos
As you've probably seen, there's been a flurry of changes today on trunk
... that means we're getting closer to a beta1 release. I think trunk
will stabilize a bit now, as there's no big remaining code changes that
should really go in before the beta1 (correct me if I'm wrong).
Before doing that though, I'd like to ask everyone to do some last
minute testing, to be sure we won't release something that has some big
flaws in it. Especially important would be the testing of the #5064
changes, as I was not able to do it fully myself.
Last minor pending changes are #3965, #5954 (eventually) and Alec's
patch (or mine) for the user permission cache that was sent to the list
earlier today. Maybe another last minute change that would be useful
would be to force the disabling of the old webadmin.* plugin, so that we
can be really sure that we won't get bogus reports related to the use of
the 0.10 WebAdmin plugin in 0.11beta1...
Now, I'll focus mostly on the documentation, so that we will at least
have /some/ documentation go in the beta1. That beta1 version can be
released in a few days if everything goes well. At that point, t.e.o
could be upgraded to that version. Then we can start to fight over the
"one true workflow" that we shall use (hint: the opensource-workflow [1]
was designed with t.e.o in mind, IIRC). The vulnerability_ticket plugin
[2] could be installed as well.
Once the 0.11beta1 will be out, no doubt we will have again lots of
little things to fix for 0.11, but that will hopefully only take a
matter of weeks (read: release before end of 2007), as I have the
feeling that 0.11 is quite robust those days (the scary #4465 issue put
aside).
Besides, I've started to generate the Trac API doc using epydoc and the
scripts used for the other t.e.o projects. That works great, except in
the place where we need at the same time to format docstrings with
epydoc and with the wiki formatter (e.g. docstrings for wiki macros).
Epydoc should really understand the {{{...}}} blocks...
-- Christian
[1] -
http://trac.edgewall.org/browser/trunk/contrib/workflow/opensource-workflow.ini
[2] -
http://trac.edgewall.org/browser/trunk/sample-plugins/permissions/vulnerability_tickets.py
Jonas Borgström
> Now, I'll focus mostly on the documentation, so that we will at least
> have /some/ documentation go in the beta1. That beta1 version can be
> released in a few days if everything goes well. At that point, t.e.o
> could be upgraded to that version. Then we can start to fight over the
> "one true workflow" that we shall use (hint: the opensource-workflow [1]
> was designed with t.e.o in mind, IIRC). The vulnerability_ticket plugin
> [2] could be installed as well.
I've already started preparing for the t.e.o upgrade, that's how I found
the permission cache issue yesterday. The plan is to initially install
the new version on a separate server with a copy of the database to give
us a chance to find any other performance issue or show stopper bug
before we have upgraded the real server.
But this might take a couple of days but I see no reason to hold back
beta1 for this.
Cheers,
Jonas
Manuzhai
> Before doing that though, I'd like to ask everyone to do some last
> minute testing, to be sure we won't release something that has some big
> flaws in it. Especially important would be the testing of the #5064
> changes, as I was not able to do it fully myself.
I've been running the latest Trac trunk on several boxes, seems to be
working just fine for me.
Cheers,
Manuzhai
Jeroen Ruigrok van der Werven
>Now, I'll focus mostly on the documentation, so that we will at least
>have /some/ documentation go in the beta1.
One thought that popped up in my head:
how will we handle documentation translations in the future?
Also, I started creating some images for Trac manuals.
Two images, after changing bits and pieces thanks to feedback of Alec and Odd
Simon, are the following:
http://www.in-nomine.org/~asmodai/trac.png
http://www.in-nomine.org/~asmodai/trac-small.png
I'm sure this will be useful to illustrate things quickly.
If people have some ideas for images that are needed on short term, let me
know and I'll see what I can whip up.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
No thought, no reflection, no analysis, no cultivation, no intention; let
it settle itself...
Jeroen Ruigrok van der Werven
>will stabilize a bit now, as there's no big remaining code changes that
>should really go in before the beta1 (correct me if I'm wrong).
Can't we just declare a formal feature freeze on trunk now until 0.11 has been
released?
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
In every stone sleeps a crystal...
Christian Boos
> -On [20071128 19:54], Christian Boos (cb...@neuf.fr) wrote:
>
>> ... that means we're getting closer to a beta1 release. I think trunk
>> will stabilize a bit now, as there's no big remaining code changes that
>> should really go in before the beta1 (correct me if I'm wrong).
>>
>
> Can't we just declare a formal feature freeze on trunk now until 0.11 has been
> released
We could, but I think everyone is already aware of the informal freeze...
I take this opportunity to summarize the "big remaining changes" that
are still scheduled for 0.11:
#5954 Can't use prototype in plugins as $ conflicts with jquery
There's a patch, but its somewhat big and I would have liked to get some
feedback on it. I'm somewhat reluctant to commit as-is, as I have the
feeling it can be done in a better way. So it'll probably be a 0.11.1 or
even 0.12 thing.
#6374 [PATCH] Provide a cleaner way to override macros
This would require quite some work and probably introduce some
instabilities.
So like the above one, probably be a 0.11.1 or 0.12.
#6185 Trac could be released with a different color and logo theme
It could... but I'm somewhat -0 on that, as I think it risks to disturb
a lot the people who are used to (and like) the default look'n'feel.
Changing that at the last minute will upset many. If we insist on a
different visual identity, let's do that on t.e.o. Anyway, I think #6059
will do a lot more for preventing "Wrong Trac" tickets than this.
#4716 Prepare documentation for 0.11
Of course that will still involve lots of changes, but none that should
introduce instabilities. Part of the documentation updates, I'll try to
merge soon my apidoc work, as it contains lots of docstring updates.
In addition to that, I'd like to add #5979 to the lot, which together
with with the components restructuring discussed before, will allow us
to list all ticket subsystem related ticket, all versioncontrol related
ones, etc.
Finally, I'd like to propose a minor cosmetic fix, which is to set the
border width of the query filters / column selector fieldsets to 0 when
collapsed. I think this looks much nicer than an empty fieldset page wide.
-- Christian
Emmanuel Blot
> a lot the people who are used to (and like) the default look'n'feel.
> Changing that at the last minute will upset many. If we insist on a
> different visual identity, let's do that on t.e.o.
> Anyway, I think #6059
> will do a lot more for preventing "Wrong Trac" tickets than this.
... although I really don't think #6059 may help: people just don't read ;-)
Cheers,
Manu
Jeroen Ruigrok van der Werven
>> Anyway, I think #6059
>> will do a lot more for preventing "Wrong Trac" tickets than this.
>... although I really don't think #6059 may help: people just don't read ;-)
I think Alec and Odd Simon were discussing something related to these kind of
mistakes on IRC today that should help a lot.
Noah Kantrowitz
On Tue, 11 Dec 2007, Jeroen Ruigrok van der Werven wrote:
>
> -On [20071211 22:33], Emmanuel Blot (manu...@gmail.com) wrote:
>>> Anyway, I think #6059
>>> will do a lot more for preventing "Wrong Trac" tickets than this.
>> ... although I really don't think #6059 may help: people just don't read ;-)
>
> I think Alec and Odd Simon were discussing something related to these kind of
> mistakes on IRC today that should help a lot.
I would also reeeeeeally like to get the ctxtnav stuff sorted before
releasing 0.11b1. I think this may be the last time we can fix this with
minimal plugin breakage.
--Noah
Emmanuel Blot
> releasing 0.11b1. I think this may be the last time we can fix this with
> minimal plugin breakage.
Christian Boos
Can you please elaborate? What needs to be sorted out before the beta1
and also, why do you raise this concern so late (I raised various calls
about "what needs to be fixed in beta1" in the last weeks).
At this point, I don't see anything blocking beta1, besides some
documentations updates and little fixes. I think the time for new
features or big changes is over, at the very least for the beta1. If
there's a clean and simple patch available for something else, we may
add it for 0.11 after discussing it here.
-- Christian
Noah Kantrowitz
for a week or two due to final exams. Basically we need to add
infrastructure to the navigation system to manage the ctxtnav bar in a
thematically similar fashion to the other nav bars. The reason this
needs to be done before a beta is this will break every template
currently in existence. The proposed API is something of the form
add_ctxtnav(req, tag.a('Foo', href=req.href.myplugin('foo'))), working
internally in a similar fashion to add_stylesheet and add_script. This
will also mean moving the ctxtnav div out of the individual templates
and into layout.html (hence the mass breakage).
--Noah
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Trac Development" group.
> To post to this group, send email to trac...@googlegroups.com
> To unsubscribe from this group, send email to trac-dev-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
>
Christian Boos
> This has been previously discussed on the list, though I stopped reading
> for a week or two due to final exams. Basically we need to add
> infrastructure to the navigation system to manage the ctxtnav bar in a
> thematically similar fashion to the other nav bars. The reason this
> needs to be done before a beta is this will break every template
> currently in existence. The proposed API is something of the form
> add_ctxtnav(req, tag.a('Foo', href=req.href.myplugin('foo'))), working
> internally in a similar fashion to add_stylesheet and add_script. This
> will also mean moving the ctxtnav div out of the individual templates
> and into layout.html (hence the mass breakage).
>
I agree that there are improvements to be made here, but I don't think
it's something we can realistically do for 0.11 at this point, as this
would involve a lot of work (seeing the relative complexity of all the
existing ctxnav <div>s), not the mention the "mass breakage" thing. If
0.11 plugins really need to extend the ctxnav, they can probably do so
using an ITemplateStreamFilter anyway.
I rather think this refactoring fits well with the 0.12 goals already
mentioned elsewhere [1]. In particular, one goal would be to actually
/remove/ all the layout related stuff from the Request, as that part of
the code is quite fragile (see e.g.
http://trac.edgewall.org/changeset/6135), and not to add more to it.
-- Christian
[1] - see "improve the rendering layer" in
http://groups.google.com/group/trac-dev/msg/77ab0f08a67e1a9c
Jeroen Ruigrok van der Werven
>We won't have another time when everyone is already reworking their
>templates massively, this is the best time to do it. I don't think we
>can reasonably delay this change given that.
Given the desire to put out 1-2 betas before release at the end of the year,
how feasible is this implementation for this timeframe? Note that we're
roughly at half December already.
Christopher Lenz
> Noah Kantrowitz wrote:
>> This has been previously discussed on the list, though I stopped
>> reading
>> for a week or two due to final exams. Basically we need to add
>> infrastructure to the navigation system to manage the ctxtnav bar
>> in a
>> thematically similar fashion to the other nav bars. The reason this
>> needs to be done before a beta is this will break every template
>> currently in existence. The proposed API is something of the form
>> add_ctxtnav(req, tag.a('Foo', href=req.href.myplugin('foo'))),
>> working
>> internally in a similar fashion to add_stylesheet and add_script.
>> This
>> will also mean moving the ctxtnav div out of the individual templates
>> and into layout.html (hence the mass breakage).
>>
> I agree that there are improvements to be made here, but I don't think
> it's something we can realistically do for 0.11 at this point, as this
> would involve a lot of work (seeing the relative complexity of all the
> existing ctxnav <div>s), not the mention the "mass breakage" thing. If
> 0.11 plugins really need to extend the ctxnav, they can probably do so
> using an ITemplateStreamFilter anyway.
Extending the ctxtnav has been a long standing issue that I think is
quite important, too. If Noah or someone else can come up with a patch
quickly enough, I'd be in favor of including it in 0.11, even after
b1. Otherwise, it shouldn't block.
> I rather think this refactoring fits well with the 0.12 goals already
> mentioned elsewhere [1]. In particular, one goal would be to actually
> /remove/ all the layout related stuff from the Request, as that part
> of
> the code is quite fragile (see e.g.
> http://trac.edgewall.org/changeset/6135), and not to add more to it.
Remove it and move it where to?
(Here's hoping you're not going to suggest mimeview)
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Christian Boos
Agreed.
>
>> I rather think this refactoring fits well with the 0.12 goals already
>> mentioned elsewhere [1]. In particular, one goal would be to actually
>> /remove/ all the layout related stuff from the Request, as that part
>> of
>> the code is quite fragile (see e.g.
>> http://trac.edgewall.org/changeset/6135), and not to add more to it.
>>
>
> Remove it and move it where to?
>
> (Here's hoping you're not going to suggest mimeview)
No, I rather think the template data dictionary is the right place for
that. All these informations (css, scripts, navigation links, warnings)
are meant to be used by the layout.html template and /only/ by it, so it
would be quite natural to use a 'layout' (or even the existing 'chrome')
entry in the dictionary for storing all these things.
I don't see the real need to use the Request object (not to mention the
transient "FakeRequest") as an intermediate storage. AFAICT, the various
hoops in the code are due to the way the 'chosen_handler' needs to be
known when calling Chrome.prepare_request, all this for setting the
active flag on the appropriate nav entry. I'm sure there's a simpler way
to achieve the same effect, like setting that flag a posteriori, after
chosen_handler.process_request(), perhaps as part of the populate_data()
step.
-- Christian