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<[email protected]> 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 [email protected] https://admin.fedoraproject.org/mailman/listinfo/infrastructure
