Website Proposal [Was TWiki status]
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 :)
More information about the website