Jeremy Huntwork wrote:
<snip RFC>
Well, the signal to noise ratio in this thread was probably the lowest
I've seen for a long time on this list. To say I'm disappointed in the
behaviour/attitude of certain contributors would be putting it very
mildly indeed.
That aside, here are my thoughts on Trac:
1) The source browser is far superior to our current tool, ViewCVS (now
known as ViewVC).
2) The "Timeline" feature replaces our own custom script for providing
info on recent subversion commits, meaning the maintenance burden is
shifted away from ourselves. The fact that it also logs other project
activity such as ticket changes, etc. is another point in its favour,
i.e. it becomes a One Stop Shop for looking at recent work.
3) The "Roadmap" feature will be very useful in tracking what new
features/bug fixes will be available in upcoming versions - something
the community has constantly been asking for and something I have
consistently failed to provide. By being intimately linked with the
Ticket tracker it Can't Possibly Go Wrong TM.
4) Trac provides a Wiki, which the BLFS team at least have said they
could make good use of. Although many many Wiki implementations are
around, in order to reduce admin overheads, we may as well use what Trac
provides - it's one less package to install, configure and keep up to
date with regard to security/bug fixes.
5) The Ticket tracker itself looks nice and feels much more responsive,
though as has already been pointed out, that might be due to the
hardware it is running on. Whilst the colour coding of priority gives a
quick visual indication of how important a bug is, a key/legend might be
useful.
6) The menu bar (i.e. "Wiki" "Timeline" "Roadmap"...) links have a small
triangle in their top-left corner. This, to me, suggested they might
drop-down to provide further options when clicking on them.
7) There is no "Read" link in the menu bar described above. How does
putting the rendered version of the book on the wiki.l14h.org site get
handled by Trac - is it just a couple of Rewrite rules or similar to
request that Trac just passes handling of serving the static HTML off to
Apache?
It looks as if the data conversion issue that Jeremy ran into with the
BLFS bug database has now been resolved. So, assuming there are no
other issues with the ticket tracker or source viewer parts of Trac, I
have no qualms at all in endorsing Trac as the preferred tool for those
two functions of the LFS website. I do not want this to proceed
immediately though, of course. I think another two weeks of testing by
*all* members of the community, be they developers or our beloved users,
is still necessary to ensure we can all make the best use of this tool.
If you could provide feedback about usability or layout issues with
the functionality trac provides, then now's the time to make your
feelings known, if you haven't done so already.
As far as using Trac for the website itself, we need a lot more time to
investigate issues like workflow and mirroring. There isn't any
particular rush for this though - the current site works. That said, it
would be nice to have all web content handled by one system, if nothing
else to again reduce complexity and the associated administrative
overheads incurred by running two lots of infrastructure.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
