Website Proposal [Was TWiki status]

Matthew Burgess matthew at linuxfromscratch.org
Wed Dec 8 10:42:58 PST 2004


Kevin P. Fleming wrote:
> Jeremy Huntwork wrote:
> 
>> It still needs to be fleshed out and to have a few features added.  
>> But I'm putting this forward publicly to allow anyone who wishes to 
>> comment.  I'm bringing it up only as an *option* - I fully respect 
>> everyone's current postition and right to an opinion in this regard, 
>> so, personally, no feelings on the line ;)
> 
> 
> I do like the look and feel of this site, but then I also like the look 
> and feel of the current site :-)
> 
> What really matters is whether this method will provide easier 
> maintenance, fewer rendering problems, etc. Only the website team can 
> speak to that.

Maintenance to me means several things:

1) Can content be added/changed/removed easily?

Yes, they're all static HTML files kept in an SVN repository.  As long 
as you have write access to that repository and you know HTML then you 
should be able to do what you want with relative ease.

2) Can content be published (i.e. made live) easily?

Yes, as Jeremy said, the way his server is setup, the DocRoot is simply 
a working copy of the website SVN repository.  When a commit is made to 
the repository then a post-commit hook performs an 'svn update' in that 
working copy.  Changes are therefore made live instantly, unless you're 
looking at a mirror, in which case...

3) Can content be mirrored easily?

We believe so, yes.  The *only* requirement this setup makes of this 
mirror is that they setup Apache to allow Server Side Includes (SSI). 
This can be done via a .htaccess file if the mirror admins don't want to 
allow SSI processing for the rest of their site.  Obviously we'll have 
to consult with mirror admins to ascertain whether this would cause any 
problems, but that's only necessary if the community as a whole likes 
this new design anyway.

I'm under the impression that an rsync push method would be the ideal 
solution in terms of updating mirrors, though I understand this would 
require another daemon running on the mirror server.  We currently 
allocate each mirror an rsync time to pull changes from the live site. 
Is there any reason we can't just tell them to attempt a pull every 10 
minutes (or whatever period is deemed reasonable)?  IIUC, rsync only 
transfers *changed* content, so in the event that the website hasn't 
changed since the last pull, the next attempt would be a no-op 
(admittedly there'll be *some* overhead in the call, though I have no 
idea how much).

4) Can content be backed up easily?

There have been several occurrences of scripts not quite doing what 
they're supposed to, and service has been disrupted until backups have 
been dug out and restored.  As *all* of the site is stored in an SVN 
repository, it's simply a case of re-checking that repo out to the 
working copy.  If *both* the working copy and the repo get deleted at 
the same time, I think we've got bigger issues to worry about than 
*just* the website :)

5) What about the books and patches?

Getting the books rendered into the website is simply a matter of 
running the relevant render-*-book.sh script and pointing it to the 
working copy of the website.  We've not quite worked out the patches 
integration yet, though it would likely follow a similar style to the 
book integration (i.e. just copy the patches from a working copy of the 
patches repo into the working copy of the website repo).

Have I missed anything?

One further point: I personally don't have a problem with Wikis - 
they're good at what they do - i.e. provide the ability for a 
*community-driven* website.  But I don't think that is required for the 
LFS site.  Certainly, there are occasions/areas where community editable 
pages are nice-to-have, like works-in-progress.  But things like 
http://wiki.linuxfromscratch.org/index.php?pagename=SsSs annoy me 
incredibly, and lower the professionalism of a site IMO.  So, I think a 
'wiki.linuxfromscratch.org' area could feasibly still exist and be 
useful for those that need/want its features, but I don't think that 
having the main LFS site as a Wiki is the way to go.  From my memory of 
previous discussions, it certainly would seem to put an increased burden 
on mirror maintainers

OK, I think I'm done.  I'll don my asbestos suit now :)

Regards,

Matt.



More information about the website mailing list