NOTE: Federation is disabled on this instance!You can test federation between the following instances:
Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
Use this as basis: https://wiki.gnome.org/MaintainersCorner/
Useful things, even for maintainers in general:
Example for page of GNU project:
The idea is as follows.
To make it easy to keep the order in FTP, there will be 4 main directories which will map to wiki pages and fill the following purposes:
readme: Collects extracted partial READMEs of all projects, mainly for inlining into each project’s main page. Or maybe a different setup, see below.
internal: Collects compiled HTML full reference pages of all (minor?) releases of all program and library projects that have code reference.
manual: Collects compiled manuals in several formats (like on GNU’s website, check their gendoc script) of all projects that have manuals. For libraries it’s usually doxygen-made API reference and tutorial.
manpages: Collects all manpages of all projects that have them
Since these are generated and not manually made, it may be a good idea to put them in a separate underlay, maybe not in the FTP server. Currently they have a separate underlay,
My first idea was to inline the package READMEs into the website. But there is a major weakness: Nothing in them generated automatically. Each package will have its own README in version control, even if they have many common parts. After realizing I can generate the common parts, I had a new idea: Have a readme page on the wiki, possibly using templates for the common parts. The package README will simply be generated from it.
That, of course, is a problem too - people should always have a full README in the package. Would it be copied manually or automatically? How to avoid cluttering the git log with minor README type fix commits?
Then I checked GNU’s ones and I realized the thing is that they are separate files. The content is not copied around or generated. Each maintainer simply knows they need to update both the README and the project page.
Therefore, by default, this must work: Manually written separate files. When each package has its own maintainer, it’s reasonable effort. On the other hand, I’m working alone right now and many new packages will come, so saving work by automating things may be a good idea.
Another option is to have SOME readme sections in git, and the rest generated when building.
The general direction should probably be having an option to save work by:
Let’s examine autoconf and sif, and compare.
This is supposed to be the webpage of Sif. It’s supposed to have:
The parts from README will probably be right at the address of this page, but not necessarily by putting the README in underlay - it will be in underlay as a subpage, and will be [[ikiwiki/directive/inline]]d here.
The 2 first kinds will be made with a script and written into the website:
Note that the API reference will need to be there at the same time for all releases, and there will need to be symlinks like “stable” and “latest”. The main page for each reference will contain a list of the available versions present. It can either be done using ikiwiki manually by adding links to the source with a script and manually
git-pushing the result, or the final HTML can be generated externally, separate from the wiki source and automated: e.g. detect versions by looking at folder contents instead of a manually managed list.
I could use ikiwiki template pages for that, to help automate and generalize.