Archaic wrote: > 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 site. > 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: [a href="http://svn.linuxfromscratch.org/viewcvs.cgi/trunk/bootscripts/README?rev=4318&view=markup";] Bootscript README[/a] 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, you'd write: source:/trunk/bootscripts/README or optionally, if you want to specify a certain revision source:/trunk/bootscripts/[EMAIL PROTECTED] 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 > ability. 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: http://wiki.linuxfromscratch.org/lfs/wiki/TracPermissions > 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 > content. 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 > website. 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 mirroring Trac. 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 sub-project. * 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 isn't lost. * 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. ;) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
