We're getting quite close to being able to release a beta of 0.12. While there are still a few important tickets to be finished first (#9060 for example), we're really getting there.
I'm going to update the Trac Guide on t.e.o in a few days, moving the 0.12/ pages to the toplevel. The current toplevel pages will be archived below 0.11/. It would be nice to get some proof reading first, see http://trac.edgewall.org/wiki/0.12 (for some pages it has already been done, check the history).
Actually, that pre-release version of 0.12 could even be called 0.12rc1, as I don't expect many changes till the final release. Also, we may still want to release 0.11.8 in parallel, as I messed up a few things with 0.11.7 (e.g. r9391, to be backported).
> We're getting quite close to being able to release a beta of 0.12. > While there are still a few important tickets to be finished first > (#9060 for example), we're really getting there.
AFAIK, 0.12 needs Genshi > 0.5.1[1], but 0.6 is not yet released[2]. For Debian (and other distribution as well, I assume) it would be nice to have a Genshi release before Trac RCs. Are there any plans to synchronise Genshi 0.6 and Trac 0.12 releases? Thanks in advance!
> Actually, that pre-release version of 0.12 could even be called > 0.12rc1, as I don't expect many changes till the final release. > Also, we may still want to release 0.11.8 in parallel, as I messed > up a few things with 0.11.7 (e.g. r9391, to be backported).
Is there a plan when 0.11.8 can be released? I ask, because Debian is about to freeze (don't hold your breath) and it would be nice to have 0.11.8 in. Thanks in advance!
> Quoting "Christian Boos" <cb...@neuf.fr>: >> We're getting quite close to being able to release a beta of 0.12. >> While there are still a few important tickets to be finished first >> (#9060 for example), we're really getting there.
> AFAIK, 0.12 needs Genshi > 0.5.1[1], but 0.6 is not yet released[2]. > For Debian (and other distribution as well, I assume) it would be > nice to have a Genshi release before Trac RCs.
Yes, it would be nice.
> Are there any plans to synchronise Genshi 0.6 and Trac 0.12 releases? > Thanks in advance!
There's no plan, only hope ;-)
More seriously, I'm not really at ease with the fact that either Genshi and Babel are more or less on life support, since Christopher has switched to other interests. Pedro Algarvio seems our best chance here ;-) Pedro?
> Quoting "Christian Boos" <cb...@neuf.fr>: >> Actually, that pre-release version of 0.12 could even be called >> 0.12rc1, as I don't expect many changes till the final release. Also, >> we may still want to release 0.11.8 in parallel, as I messed up a few >> things with 0.11.7 (e.g. r9391, to be backported).
> Is there a plan when 0.11.8 can be released? I ask, because Debian > is about to freeze (don't hold your breath) and it would be nice > to have 0.11.8 in. Thanks in advance!
No, not yet.
But besides the change I was talking about (#9103), I see only #9128, + fixing a glitch in the RELEASE note (thanks Anatoly), + a fix for a (tiny) security issue that has been reported meanwhile. We could even call that 0.11.7.1, as the scope is rather small. That release could happen "soon" as well.
Christian Boos <cb...@neuf.fr> writes: > On 3/22/2010 2:45 PM, W. Martin Borgert wrote: >> Quoting "Christian Boos" <cb...@neuf.fr>: >>> We're getting quite close to being able to release a beta of >>> 0.12. While there are still a few important tickets to be finished >>> first (#9060 for example), we're really getting there.
>> AFAIK, 0.12 needs Genshi > 0.5.1[1], but 0.6 is not yet released[2]. >> For Debian (and other distribution as well, I assume) it would be >> nice to have a Genshi release before Trac RCs.
> Yes, it would be nice.
>> Are there any plans to synchronise Genshi 0.6 and Trac 0.12 >> releases? Thanks in advance!
> There's no plan, only hope ;-)
> More seriously, I'm not really at ease with the fact that either > Genshi and Babel are more or less on life support, since Christopher > has switched to other interests. Pedro Algarvio seems our best chance > here ;-) Pedro?
Speaking as someone using trac seriously, it seems scary to be talking about a 0.12 release that depends on unreleased versions of other tools. If that's really the case, then I'd say the other tools need to be encouraged/helped to get to release or forked and released before 0.12 has an rc. When you think about putting trac into a packaging system, depending on unreleased code means creating a new -beta package for that code from svn/git/whatever, or updating the allegedly stable package to an unreleased version.
>>>> We're getting quite close to being able to release a beta of >>>> 0.12. While there are still a few important tickets to be finished >>>> first (#9060 for example), we're really getting there.
>>> AFAIK, 0.12 needs Genshi> 0.5.1[1], but 0.6 is not yet released[2]. >>> For Debian (and other distribution as well, I assume) it would be >>> nice to have a Genshi release before Trac RCs.
>> Yes, it would be nice.
>>> Are there any plans to synchronise Genshi 0.6 and Trac 0.12 >>> releases? Thanks in advance!
>> There's no plan, only hope ;-)
>> More seriously, I'm not really at ease with the fact that either >> Genshi and Babel are more or less on life support, since Christopher >> has switched to other interests. Pedro Algarvio seems our best chance >> here ;-) Pedro?
> Speaking as someone using trac seriously, it seems scary to be talking > about a 0.12 release that depends on unreleased versions of other tools.
I understand and share your concerns.
> If that's really the case, then I'd say the other tools need to be > encouraged/helped to get to release or forked and released before 0.12 > has an rc.
We have considered that. It looks like we're going to have a Babel 0.9.5 really soon (I see the packages on ftp.edgewall.org as I'm writing this), and perhaps a Genshi 0.6 release at some later point (keep finger crossed).
The fact remains that those libraries are currently strong dependencies for Trac (Genshi even more so than Babel), and neither has currently the level of maintenance we were used to have, every sign indicates this trend won't change. I've also stopped to hope there will be any drastic performance improvement, and while there has been some improvements last year (1), I rather feel that this means that all that could be realistically done has now been done on this topic. Of course, theoretically someone could step up anytime and bring in a radically new idea and dramatically increase performance, but that's precisely what I've been hoping for since the last 4 years. While there has been such attempts, made by bright minds, none really succeeded.
So don't get me wrong, I actually like Genshi, I was really pleased to ditch the ugly and hard to maintain Clearsilver templates and enthusiastically converted most of the Trac templates to it. I also helped to fix (easy) Genshi issues during the early stage of its development, but was always intimidated by its complexity. I still enjoy very much *using* Genshi from a developer perspective, but for the reasons exposed above, from the point of view of Trac maintenance and its future evolution, we really have a situation to address, lots of users are still hesitant to move away from Trac *0.10* because of performance concerns (Genshi is perhaps not the only factor at play there, but it's an important one).
It seems however that there could be a way forward, by considering once again a switch of the templating engine. This time it would be in favor of Jinja2 (2), which seems to have a great momentum and have the adequate capabilities and speed we need. In addition, its main developer is also a long time Trac supporter and has shown interest in supporting us for the switch (hello Armin!).
There has been some informal discussions on this topic on the #trac IRC channel, so the logical next step is to discuss it more formally here on Trac-dev. To me at least, the status quo is not really an option. I'm aware this will cause some inconvenience, especially for the plugins that currently depend on stream filters. However this will be mitigated by the fact that we can continue to support Genshi, and migrate to Jinja2 only gradually, starting with the time critical parts (like the changeset view, the browser view and the timeline).
> On 3/23/2010 12:43 AM, Greg Troxel wrote: >> Speaking as someone using trac seriously, it seems scary to be talking >> about a 0.12 release that depends on unreleased versions of other tools.
> I understand and share your concerns.
>> If that's really the case, then I'd say the other tools need to be >> encouraged/helped to get to release or forked and released before 0.12 >> has an rc.
> We have considered that. It looks like we're going to have a Babel > 0.9.5 really soon (I see the packages on ftp.edgewall.org as I'm > writing this), and perhaps a Genshi 0.6 release at some later point > (keep finger crossed).
> The fact remains that those libraries are currently strong > dependencies for Trac (Genshi even more so than Babel), and neither > has currently the level of maintenance we were used to have, every > sign indicates this trend won't change. I've also stopped to hope > there will be any drastic performance improvement, and while there has > been some improvements last year (1), I rather feel that this means > that all that could be realistically done has now been done on this > topic. Of course, theoretically someone could step up anytime and > bring in a radically new idea and dramatically increase performance, > but that's precisely what I've been hoping for since the last 4 > years. While there has been such attempts, made by bright minds, none > really succeeded.
Thanks for the detailed explanation. Everything you say sounds quite reasonable in term of how trac got where it is and the way forward.
But, if Genshi doesn't have a release that can be used (reasonably) with trac, then it should be a small matter of making a tarball from Genshi's CM ystems and calling it Genshi-0.5.80 or GenshiTrac-0.5.80 if it's socially awkward to call it Genshi-0.6. Then packaging systems can either update their Genshi package or make a GenshiTrac package, and there's no more packaging issue. (I realize this doesn't address the lack of maintainer time issue. But if something in svn is good enough and required, it should be declared a release before 0.12 is in RC.)
>>> Speaking as someone using trac seriously, it seems scary to be talking >>> about a 0.12 release that depends on unreleased versions of other tools.
>> I understand and share your concerns.
>>> If that's really the case, then I'd say the other tools need to be >>> encouraged/helped to get to release or forked and released before 0.12 >>> has an rc.
>> We have considered that. It looks like we're going to have a Babel >> 0.9.5 really soon (I see the packages on ftp.edgewall.org as I'm >> writing this), and perhaps a Genshi 0.6 release at some later point >> (keep finger crossed).
>> The fact remains that those libraries are currently strong >> dependencies for Trac (Genshi even more so than Babel), and neither >> has currently the level of maintenance we were used to have, every >> sign indicates this trend won't change. I've also stopped to hope >> there will be any drastic performance improvement, and while there has >> been some improvements last year (1), I rather feel that this means >> that all that could be realistically done has now been done on this >> topic. Of course, theoretically someone could step up anytime and >> bring in a radically new idea and dramatically increase performance, >> but that's precisely what I've been hoping for since the last 4 >> years. While there has been such attempts, made by bright minds, none >> really succeeded.
> Thanks for the detailed explanation. Everything you say sounds quite > reasonable in term of how trac got where it is and the way forward.
> But, if Genshi doesn't have a release that can be used (reasonably) with > trac, then it should be a small matter of making a tarball from Genshi's > CM ystems and calling it Genshi-0.5.80 or GenshiTrac-0.5.80 if it's > socially awkward to call it Genshi-0.6. Then packaging systems can > either update their Genshi package or make a GenshiTrac package, and > there's no more packaging issue. (I realize this doesn't address the > lack of maintainer time issue. But if something in svn is good enough > and required, it should be declared a release before 0.12 is in RC.)
That's why we won't after all release a 0.12rc1 directly, in the coming days, but first make a 0.12beta. I hope it's more acceptable to have a "beta" version depending on an unreleased package than a RC :-)
We'll then release the 0.12rc1 version after the Genshi 0.6 release.
But if it's still not released in a month or so from now, then we could indeed integrate the genshi/ files as tracdep/genshi.* and make sure that the Trac plugins importing the genshi modules will actually find our tracdep.genshi ones (hopefully a `sys.modules['genshi'] = tracdep.genshi` will be enough).
On 7 Apr, 2010, at 14:53 , W. Martin Borgert wrote:
> Quoting "Christian Boos" <cb...@neuf.fr>: >> Of course, theoretically someone could step up anytime and bring in a radically new idea
> Like building Trac 0.13 completely on top of Django? :~)
+1 I'll start doing it tomorrow if needed... too much technology to take care of now, and given the limited development capacity, wouldn't be that bad to focus on features more than technology :-)
> But if it's still not released in a month or so from now, then we could > indeed integrate the genshi/ files as tracdep/genshi.* and make sure > that the Trac plugins importing the genshi modules will actually find > our tracdep.genshi ones (hopefully a `sys.modules['genshi'] = > tracdep.genshi` will be enough).
I'll cross my fingers for a release instead. Mucking about with imports or sys.path is bound to cause problems, as it does with Twill. There's a thread on the genshi and babel lists about this.
>>> Of course, theoretically someone could step up anytime and bring in a radically new idea
>> Like building Trac 0.13 completely on top of Django? :~)
> +1 I'll start doing it tomorrow if needed... too much technology to take care of now, and given the limited development capacity, wouldn't be that bad to focus on features more than technology :-)
Well, I was talking about a new idea to improve Genshi performance...
Rewriting Trac on top of Django is a *very* different topic. While I also would like to be able to focus on Trac features rather than on the supporting technology, I have the feeling that doing a switch to Django would do the exact opposite, make us focus again on the technology (and eventually be limited by the constraints imposed upon us by the framework) rather than on our features... We now have a base on which we can build on, and if there wouldn't have been the problems related to Genshi maintenance, I would even have been willing to close the eyes a bit longer on the performance side and not have /any/ change in the infrastructure for the next versions (besides a switch to Python 2.5, but now it's me who's digressing ;-) ).
And there's already Basie, for those interested by a Trac-like system on top of Django (http://basieproject.org/).
>> But if it's still not released in a month or so from now, then we could >> indeed integrate the genshi/ files as tracdep/genshi.* and make sure >> that the Trac plugins importing the genshi modules will actually find >> our tracdep.genshi ones (hopefully a `sys.modules['genshi'] = >> tracdep.genshi` will be enough).
> I'll cross my fingers for a release instead. Mucking about with imports > or sys.path is bound to cause problems, as it does with Twill. There's > a thread on the genshi and babel lists about this.
... in which thread Remy already replied that the situation is different, as we're loading Genshi first, then loading the plugins. And I think it make more sense to talk about such hacks on this list rather than on the Genshi list, so I'd prefer we continue that discussion here.
>>>>> We're getting quite close to being able to release a beta of >>>>> 0.12. While there are still a few important tickets to be finished >>>>> first (#9060 for example), we're really getting there.
>>>> AFAIK, 0.12 needs Genshi> 0.5.1[1], but 0.6 is not yet >>>> released[2]. >>>> For Debian (and other distribution as well, I assume) it would be >>>> nice to have a Genshi release before Trac RCs.
>>> Yes, it would be nice.
>>>> Are there any plans to synchronise Genshi 0.6 and Trac 0.12 >>>> releases? Thanks in advance!
>>> There's no plan, only hope ;-)
>>> More seriously, I'm not really at ease with the fact that either >>> Genshi and Babel are more or less on life support, since >>> Christopher >>> has switched to other interests. Pedro Algarvio seems our best >>> chance >>> here ;-) Pedro?
>> Speaking as someone using trac seriously, it seems scary to be >> talking >> about a 0.12 release that depends on unreleased versions of other >> tools.
> I understand and share your concerns.
>> If that's really the case, then I'd say the other tools need to be >> encouraged/helped to get to release or forked and released before >> 0.12 >> has an rc.
> We have considered that. It looks like we're going to have a Babel > 0.9.5 really soon (I see the packages on ftp.edgewall.org as I'm > writing this), and perhaps a Genshi 0.6 release at some later point > (keep finger crossed).
> The fact remains that those libraries are currently strong > dependencies for Trac (Genshi even more so than Babel), and neither > has currently the level of maintenance we were used to have, every > sign indicates this trend won't change. I've also stopped to hope > there will be any drastic performance improvement, and while there > has been some improvements last year (1), I rather feel that this > means that all that could be realistically done has now been done on > this topic. Of course, theoretically someone could step up anytime > and bring in a radically new idea and dramatically increase > performance, but that's precisely what I've been hoping for since > the last 4 years. While there has been such attempts, made by bright > minds, none really succeeded.
> So don't get me wrong, I actually like Genshi, I was really pleased > to ditch the ugly and hard to maintain Clearsilver templates and > enthusiastically converted most of the Trac templates to it. I also > helped to fix (easy) Genshi issues during the early stage of its > development, but was always intimidated by its complexity. I still > enjoy very much *using* Genshi from a developer perspective, but for > the reasons exposed above, from the point of view of Trac > maintenance and its future evolution, we really have a situation to > address, lots of users are still hesitant to move away from Trac > *0.10* because of performance concerns (Genshi is perhaps not the > only factor at play there, but it's an important one).
> It seems however that there could be a way forward, by considering > once again a switch of the templating engine. This time it would be > in favor of Jinja2 (2), which seems to have a great momentum and > have the adequate capabilities and speed we need. In addition, its > main developer is also a long time Trac supporter and has shown > interest in supporting us for the switch (hello Armin!).
> There has been some informal discussions on this topic on the #trac > IRC channel, so the logical next step is to discuss it more formally > here on Trac-dev. To me at least, the status quo is not really an > option. I'm aware this will cause some inconvenience, especially for > the plugins that currently depend on stream filters. However this > will be mitigated by the fact that we can continue to support > Genshi, and migrate to Jinja2 only gradually, starting with the time > critical parts (like the changeset view, the browser view and the > timeline).
While I agree that this is needed, we should be clear about the impact; partially supporting Genshi doesn''t really mitigate not support stream filters, since Genshi or not we can't filter a non- Genshi and the whole point of stream filters is to allow UI changes on other peoples' pages. The other question is how to support themes on the converted pages, and I have no good answer for that.
> But if it's still not released in a month or so from now, then we > could indeed integrate the genshi/ files as tracdep/genshi.* and > make sure that the Trac plugins importing the genshi modules will > actually find our tracdep.genshi ones (hopefully a > `sys.modules['genshi'] = tracdep.genshi` will be enough).
I think, this model is not an option for Debian nor for most other Linux distributions. Debian, and surely others as well, work very hard on removing embedded code copies. Adding a new copy would be a stop in the wrong direction. Embedded code copies make QA work, especially security fixes, very hard. Also, they bloat the archive. They constitute a policy violation in Debian. It would be preferable to find an alternative solution.
> On 3/23/2010 12:43 AM, Greg Troxel wrote: >> Speaking as someone using trac seriously, it seems scary to be talking >> about a 0.12 release that depends on unreleased versions of other tools.
> I understand and share your concerns.
>> If that's really the case, then I'd say the other tools need to be >> encouraged/helped to get to release or forked and released before 0.12 >> has an rc.
> We have considered that. It looks like we're going to have a Babel 0.9.5 really soon (I see the packages on ftp.edgewall.org as I'm writing this), and perhaps a Genshi 0.6 release at some later point (keep finger crossed).
The Babel maintenance release has made it out of the door today. I will do my best to get Genshi 0.6 out by next week.
To be honest, I'm not sure what's going to happen after that, and you're certainly right to be pessimistic. I'm really sorry about how the situation has turned out for Trac.
Yes, my interests have mostly shifted elsewhere. I still believe that both Babel and Genshi are worth being further maintained and enhanced, and I'm still interested to actually do the work, but obviously I'm not able to allot anywhere enough spare time to that task right now. What's more, I've unforunately been unable to attract other developers to contribute significantly to either code base, let alone build a strong community.
That's not to say that I consider either project end-of-life. I still use them for my own stuff. But I'm the pretty much the single point of failure for both projects, and I've been failing badly and consistently at maintaining/enhancing them for some time now. Sorry.
> The fact remains that those libraries are currently strong dependencies for Trac (Genshi even more so than Babel), and neither has currently the level of maintenance we were used to have, every sign indicates this trend won't change. I've also stopped to hope there will be any drastic performance improvement, and while there has been some improvements last year (1), I rather feel that this means that all that could be realistically done has now been done on this topic. Of course, theoretically someone could step up anytime and bring in a radically new idea and dramatically increase performance, but that's precisely what I've been hoping for since the last 4 years. While there has been such attempts, made by bright minds, none really succeeded.
> So don't get me wrong, I actually like Genshi, I was really pleased to ditch the ugly and hard to maintain Clearsilver templates and enthusiastically converted most of the Trac templates to it. I also helped to fix (easy) Genshi issues during the early stage of its development, but was always intimidated by its complexity. I still enjoy very much *using* Genshi from a developer perspective, but for the reasons exposed above, from the point of view of Trac maintenance and its future evolution, we really have a situation to address, lots of users are still hesitant to move away from Trac *0.10* because of performance concerns (Genshi is perhaps not the only factor at play there, but it's an important one).
> It seems however that there could be a way forward, by considering once again a switch of the templating engine. This time it would be in favor of Jinja2 (2), which seems to have a great momentum and have the adequate capabilities and speed we need. In addition, its main developer is also a long time Trac supporter and has shown interest in supporting us for the switch (hello Armin!).
> There has been some informal discussions on this topic on the #trac IRC channel, so the logical next step is to discuss it more formally here on Trac-dev. To me at least, the status quo is not really an option. I'm aware this will cause some inconvenience, especially for the plugins that currently depend on stream filters. However this will be mitigated by the fact that we can continue to support Genshi, and migrate to Jinja2 only gradually, starting with the time critical parts (like the changeset view, the browser view and the timeline).
I agree that adoption of Jinja2 should be considered, it's become a very solid templating solution, and comes with both more momentum and better performance than Genshi.
But I'm not sure how a gradual transition could work. As Noah said, you can't switch some of the most important pages to Jinja and still support stream filters. Or site templates using match templates for advanced customization. You'll also need to rethink parts of the internationalization story, I guess.
If there's going to be another template engine switch, I think it's going to hurt. But it might just be worth it.
> I agree that adoption of Jinja2 should be considered, it's become a very > solid templating solution, and comes with both more momentum and better > performance than Genshi.
It's already a good sign that nobody has anything *bad* to say about Jinja2. Still, is this the only reasonable alternative? Are there other contenders out there, and what are the pros and cons of each solution?
I'm not trying to work against Jinja2, just to keep the view broad before making a choice.
> But I'm not sure how a gradual transition could work.
(snip)
> If there's going to be another template engine switch, I think it's going > to hurt. But it might just be worth it.
I'm a bit wary of how this could work out. Let's say (for the sake of argument) that we switch to Jinja for 0.13. This is a large internal change, but mostly invisible to end-users (except for better speed, which may or may not have a significant impact). Besides, we either break most of the existing plugins (if we don't transition gradually) or increase the work significantly (if we transition gradually).
So, we get a new release where:
- a big chunk of work is barely visible to end-users - plugins stop working for no (user-understandable) reason - themes and style customizations stop working
I do hope that if we go this way (and maybe a radical but painful switch with limited backward compatibility is the best solution), we can at least bundle it with a few highly visible, high value features. Improving internals is all well and good, but at the end of the day, it's the user-visible features that the users care about.
> That's why we won't after all release a 0.12rc1 directly, in the > coming days, but first make a 0.12beta. I hope it's more acceptable to > have a "beta" version depending on an unreleased package than a RC :-)
Well, I have no standing to actually complain about what people volunteer to do - just pointing out how it feels on the packaging end.
Sure, with a beta, it won't get packaged, so there's no issue.
> We'll then release the 0.12rc1 version after the Genshi 0.6 release.
That would be just fine from my viewpoint.
> But if it's still not released in a month or so from now, then we > could indeed integrate the genshi/ files as tracdep/genshi.* and make > sure that the Trac plugins importing the genshi modules will actually > find our tracdep.genshi ones (hopefully a `sys.modules['genshi'] = > tracdep.genshi` will be enough).
> It's already a good sign that nobody has anything *bad* to say about > Jinja2. Still, is this the only reasonable alternative? Are there other > contenders out there, and what are the pros and cons of each solution?
> I'm not trying to work against Jinja2, just to keep the view broad > before making a choice.
Breve [1], mako [2], and cheetah [3], off the top of my head.
> I'm a bit wary of how this could work out. Let's say (for the sake of > argument) that we switch to Jinja for 0.13. This is a large internal > change, but mostly invisible to end-users (except for better speed, > which may or may not have a significant impact). Besides, we either > break most of the existing plugins (if we don't transition gradually) or > increase the work significantly (if we transition gradually).
> So, we get a new release where:
> - a big chunk of work is barely visible to end-users > - plugins stop working for no (user-understandable) reason > - themes and style customizations stop working
> I do hope that if we go this way (and maybe a radical but painful switch > with limited backward compatibility is the best solution), we can at > least bundle it with a few highly visible, high value features. > Improving internals is all well and good, but at the end of the day, > it's the user-visible features that the users care about.
Speed of the site being one of the biggest features that users care about ;)
If we change templating engines again (for which I'm +1 atm) then I think our only real option is doing a full switch, no backwards compatibility for the following reasons:
* There is no indication that a gradual transition will provide any help with plugin transitions * Even with a compatibility layer, it's not going to be 100% and we'll probably end up breaking a bunch of plugins anyway * We can be very clear about which plugins are supported. i.e. Only plugins that specifically state they work on 0.13 will work * Breaking everything on purpose will help bring out the issues early, rather than mask them in the compatibility layer.
> -----Original Message----- > From: trac-dev@googlegroups.com [mailto:trac-dev@googlegroups.com] On > Behalf Of Remy Blank > Sent: Wednesday, April 07, 2010 3:35 PM > To: trac-dev@googlegroups.com > Subject: Re: Towards Jinja2 (was Re: [Trac-dev] Which genshi version > for Trac 0.12?)
> Whoa, activity on trac-dev! :)
> > I agree that adoption of Jinja2 should be considered, it's become a > > very solid templating solution, and comes with both more momentum and > > better performance than Genshi.
> It's already a good sign that nobody has anything *bad* to say about > Jinja2. Still, is this the only reasonable alternative? Are there other > contenders out there, and what are the pros and cons of each solution?
> I'm not trying to work against Jinja2, just to keep the view broad > before making a choice.
> > But I'm not sure how a gradual transition could work.
> (snip)
> > If there's going to be another template engine switch, I think it's > > going to hurt. But it might just be worth it.
> I'm a bit wary of how this could work out. Let's say (for the sake of > argument) that we switch to Jinja for 0.13. This is a large internal > change, but mostly invisible to end-users (except for better speed, > which may or may not have a significant impact). Besides, we either > break most of the existing plugins (if we don't transition gradually) > or increase the work significantly (if we transition gradually).
> So, we get a new release where:
> - a big chunk of work is barely visible to end-users > - plugins stop working for no (user-understandable) reason > - themes and style customizations stop working
I'm biased given how much work I've put in on ThemeEngine, but I think this is the kind of thing that we should try to ask users what they want. It seems like uptake on ThemeEngine (and other large-scale changes to the trac UI) is near zero, so even though it kills me a little inside maybe this isn't a big feature to lose. CSS-only changes to the UI (and the big system in ThemeEngine for generating them) would still work as-is.
The same goes for streamfilter plugins. What plugins out there are making good use of this? I know TagsPlugin relies on a stream filter for injecting the tag display into wiki pages. Also, could make something like stream filters (not talking about API compat, just functional similarity) the same way 0.10 injected XSRF tokens (render the full page and then parse it out again)? Maybe that will still be enough of a performance win to justify the added slowdown?
I agree with John, if a template change is in order then no backwards compatibility will just make things easier for everyone, less code = less things that can break (and less work for the core developers).
As long as there is ample warning to all plugin developers about when the transition will take place then they can upgrade their plugins to the new template system then all "end users" have to do is update their plugins along with trac. I'd suggest a long RC period if this does happen that way plugin authors can test their plugins against a trac core that is unlikely to change much.
I use the transformer genshi stream filter for editing the ticket fields in BlackMagicTicketTweaks, although changing the layout is not 100% necessary since the validation is done by the back end, it does help from the user perspective if they're not allowed to use a field then if it's disabled in the browser it saves confusion. Stream filters really do make tweaking the UI easy, I'd like something that allows the modification of the UI from the python side (no javascript) to be retained in Trac. ~Rowan
On Apr 8, 12:20 pm, "Noah Kantrowitz" <n...@coderanger.net> wrote:
> > -----Original Message----- > > From: trac-dev@googlegroups.com [mailto:trac-dev@googlegroups.com] On > > Behalf Of Remy Blank > > Sent: Wednesday, April 07, 2010 3:35 PM > > To: trac-dev@googlegroups.com > > Subject: Re: Towards Jinja2 (was Re: [Trac-dev] Which genshi version > > for Trac 0.12?)
> > Whoa, activity on trac-dev! :)
> > > I agree that adoption of Jinja2 should be considered, it's become a > > > very solid templating solution, and comes with both more momentum and > > > better performance than Genshi.
> > It's already a good sign that nobody has anything *bad* to say about > > Jinja2. Still, is this the only reasonable alternative? Are there other > > contenders out there, and what are the pros and cons of each solution?
> > I'm not trying to work against Jinja2, just to keep the view broad > > before making a choice.
> > > But I'm not sure how a gradual transition could work.
> > (snip)
> > > If there's going to be another template engine switch, I think it's > > > going to hurt. But it might just be worth it.
> > I'm a bit wary of how this could work out. Let's say (for the sake of > > argument) that we switch to Jinja for 0.13. This is a large internal > > change, but mostly invisible to end-users (except for better speed, > > which may or may not have a significant impact). Besides, we either > > break most of the existing plugins (if we don't transition gradually) > > or increase the work significantly (if we transition gradually).
> > So, we get a new release where:
> > - a big chunk of work is barely visible to end-users > > - plugins stop working for no (user-understandable) reason > > - themes and style customizations stop working
> I'm biased given how much work I've put in on ThemeEngine, but I think this > is the kind of thing that we should try to ask users what they want. It > seems like uptake on ThemeEngine (and other large-scale changes to the trac > UI) is near zero, so even though it kills me a little inside maybe this > isn't a big feature to lose. CSS-only changes to the UI (and the big system > in ThemeEngine for generating them) would still work as-is.
> The same goes for streamfilter plugins. What plugins out there are making > good use of this? I know TagsPlugin relies on a stream filter for injecting > the tag display into wiki pages. Also, could make something like stream > filters (not talking about API compat, just functional similarity) the same > way 0.10 injected XSRF tokens (render the full page and then parse it out > again)? Maybe that will still be enough of a performance win to justify the > added slowdown?
