[Analysis] Templates: The good, the bad, the ugly

Matty mattyt at tpg.com.au
Sat Dec 11 14:06:42 UTC 2004


On Mon, 2004-12-06 at 18:34 -0500, Jake wrote:

> Templates first came to life in Bugzilla as part of a completely unrelated
> patch with little to no discussion beforehand about the implimentation,
> template package, etc.).

Sounds like business as usual.  Sometimes it's the only way we get off
our butts to do something.  RHBZ had templates a long time before us.

That's not to say I don't agree with this being a problem, I'm pretty
sure I've complained about this in the past.

> Speed. While I haven't run any benchmarks, I've gotta believe that the
> introduction of another processing engine (eg, Template Toolkit) had a
> negative impact on our speed.

Probably, but they could also make the really serious performance
problems easier to diagnose and solve in future, by reducing code size.
That's often the case with adding new abstraction layers or
modularising.

> It would have been nice if discussion had transpired about methods for
> templatization before any work was done/package was chosen. I'm going from
> distant memory a lot here, but as I recall there wasn't much discussion
> about what was the best plan of attack.

I think Myk said that it was more flexible, and flexibility certainly
hasn't been much of a problem since.  I'm not sure we had much hope at
the time of knowing the kind of flexibility we needed anyway so
discussion probably wouldn't have helped too much on this particular
issue, although I guess some (public) analysis of RHBZ would have been
useful.

> It also would have been nice to have taken the scope of such a change into
> consideration before implimenting it. While templates are nice to have, it
> would have been possible to release 2.16 without the templates and have
> had that been a stated goal for 2.18... possibly even the only stated
> goal. It would have given more time for discussion/proof of concept and
> would have allowed us to step up the pace of releases (a long stated
> goal).

Possibly we now have more experience with wide-ranging changes and can
plan them better now, just as we've learnt plenty about security in the
past.  I think the release process changes over the last year or so are
a good start.





More information about the developers mailing list