RFC: Implementing Trac [long]
jhuntwork at linuxfromscratch.org
Mon Jan 16 08:56:06 PST 2006
> So basically you are adding undue weight to your preference make option
> 2 require much more support that option 1? That seems jaded. First,
> let's throw out the facts.
I never really thoroughly responded to this, though I should have. I
don't know if this will change anyone's viewpoint. If not, that's fine,
but at least we should consider the positives of using Trac as the main
> 1. The HTML as it stands is basically static.
While that *can* be a good thing, with the Trac system, you lose power
and possibilities by not using the wiki for the site. For example,
currently, if you want to link to some part of the repo on the website
you have to:
1) Check out a copy of the www2 repo if you don't have it already,
otherwise make sure you run 'svn up'
2) Open up a broswer and find the file you want (I almost never remember
the full path of the file I'm looking for...)
3) Create a link in the page by copying the link from the browser (or
worse, typing it in manually). For example:
4) Go over your new text carefully to make sure you didn't create a
typo, trying to parse the thing visually in your head. (And unless you
set up some personal web space somewhere that mimics the apache setup of
the main site, you can't preview your changes).
5) Commit, supplying a password each time you commit, if you're doing
this remotely, which is likely.
6) Check the LFS site now to make sure it came out like you intended. If
not, you have to go back and fix your mistake and re-commit.
With trac you would:
1) Login to the trac system
2) Go to the page you want to edit and click 'Edit' on the bottom
3) Add a link to the file in the Repo. Using the same example as above,
or optionally, if you want to specify a certain revision
source:/trunk/bootscripts/README at 4318
4) Hit the 'Preview' button to show you what the page will look like
5) Once you're satisfied with the Preview hit 'Save'
Especially when you consider the time involved, I would say that the
trac way is easier. Similar sorts of links can be done directly to the bugs.
> 2. The people who are allowed to edit the pages already have the
Yes, but we would still have to set up permissions in Trac if we use it
instead of ViewCVS and Bugzilla. So, this work is going to happen again
anyway. Also, if we like, we can really fine tune with each person what
permissions they have for each trac environment (one for each
sub-project). There is a whole range of permissions Trac allows. See:
> 3. The website is stable and works well.
Trac could also be stable and work well. :) In fact, I would say in some
ways it would work much better than our current setup. Which is why I'd
like to use it.
> 4. The website includes some already scripted and automated dynamic
Yes, it does. I don't see why this couldn't continue to be used in Trac.
It might take a little work and imagination, but I don't see why it
can't be done. In fact, some of our current scripts and dynamic content
(mostly, it's just the svn logs and book renderings), could use a little
more work to make them truly useful.
> 5. Making the main site a wiki requires that we can no longer mirror the
This is not necessarily true, and Archaic, its a bit of an uneducated
blanket statement. It's true that it might be more work than it is worth
to get the trac environment out to the mirrors, but we don't know yet
that we *can't*. I am going to try to look up more information about
At the least, we might very well be able to push out static content to
the mirrors with Wiki or Trac links back to the main site.
Also, I'd be curious to know just how much the web mirrors are useful
and are being used. My guess would be not as much as we'd hope.
> Now please explain why option 1 is better. For those who may have
> forgotten the OP, option one is to use trac for the main site, viewCVS,
> and bugzilla. Option 2 is to use trac for viewCVS and bugzilla and leave
> the main site's infrastructure in place.
* Option 1, using only trac and dropping the static site, would allow us
to use *all* of Trac's built in features to the fullest degree.
* It would help make website editing easier, and less prone to mistakes,
especially when considering the preview feature.
* It allows fine-tuning of permissions, if we so desire, broken up by
* There is a backup feature, to back up the entire trac environment, and
I believe it is possible to revert to specific Wiki page versions (I
have to verify that) so what we currently gain by using the svn repo
* Maintenance of the site is cut down, especially if we get to be
liberal about who we allow to edit Wiki pages (as we get used to seeing
people on the lists, who always offer reliable help or useful comments,
we can allow wiki write privs before we ever need consider them for
editor). Another important thing, IMHO, about using a Wiki in this way
is that it encourages new ones to get involved.
There may be more. I'm still thinking. ;)
More information about the website