Why don't we Stick with Genshi for now. And if we need to in the future develop it for our own needs. Personally I think it will benefit us in 2 ways. 1. We have minimal disruption and downtime of key fedoraproject.org Websites 2. We will eventually have it customized and re-developed by the Fedora Project and will give us a new medium to promote fedora to the open source community. If we ever need it, I personally would be interested in maintaining Genshi as part of the fedora project. On 15/04/2010 20:25, Stephen John Smoogen wrote: > On Thu, Apr 15, 2010 at 9:49 AM, Luke Macken<lmacken@xxxxxxxxxx> wrote: > >> The future of Genshi is currently in question... >> >> http://groups.google.com/group/turbogears-trunk/t/ec921035779324e9 >> >> We currently rely on the Genshi templating engine for: >> >> * all static fedoraproject.org sites are compiled down to HTML from Genshi >> * Elections >> * FAS >> * PackageDB >> * Smolt >> * Trac (which will be switching to Jinja2 in the next release) >> >> It's also worth noting that Bodhi& Mirrormanager still rely on Kid, the unmaintained precursor to Genshi. >> >> Quoting upstream: >> >> """ >> 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. >> >> 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. >> """ >> >> So, what are our options? >> >> 1) Find contributors that are willing and able to help sustain this project upstream >> 2) Stay on Genshi and rely on the Fedora/EPEL maintainers to fix bugs as they are filed >> 3) Try and utilize http://pypi.python.org/pypi/chameleon.genshi instead, which is supposed to be able to run Genshi templates faster than Genshi can. >> (Note: TG2 was going to support this engine, but apparently it needs a bit more work. It may still be worth looking into, though.) >> 4) Port to another templating engine (Jinja2, Mako, etc) >> >> We obviously have a vested interest in keeping this project alive, so #1 is ideal. >> >> Porting will require a bit of effort. The TurboGears2 port of bodhi that I'm working on will use the Mako templating engine (which is actively maintained by the SQLAlchemy author). However, it seems we've taken the #2 route with Kid for the past 5 years, and I've had zero issues with it. >> >> There was talk at PyCon this year about changing the TurboGears2 default templating engine to Mako. The only reason not to for 2.0 was to ease the 1.0->2.0 transition. However, everyone I spoke to was in favor of switching the defaults in 2.1. >> > Looking at the options and other parts.. I think staying with Genshi > for the most part would be our 'best' bet. If someone is really > motivated or if we are doing a huge code change in something then > maybe it would be attractive for changing. > > > _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
