> There's also a group of people wanting to do something else for the
> developer site. I went to some of their meetings, but haven't had time
> to keep up. I don't know their status.
Same here. I think if the developer site group chooses at some point to
go for the same solution as the user help site, they can just do it by
re-using parts of the infra setup, though from what I understood the
group's goal was to switch to a Drupal-like CMS. Any updates there?
There are two categories of content for the developers website:
- API references
- guides, tutorials, white papers, …
A CMS makes sense for the second category; we could literally run a WordPress installation on
developer.gnome.org *today*, and with minimal effort port the existing content there.
On the other hand, though, the API references are, and will continue to be for the foreseeable future, built from the code in the repository of each module; a CMS makes little sense in that case. That's why I was proposing to use the CI infrastructure to build API references from repository events, like tagging a release, or pushing to a branch—or even pushing to a MR, if we want to get an immediate render of the documentation changes it introduces.
The problem with generating documentation from CI is that publishing it is kind of complicated. When using GitLab pages, the CI will blow away everything on deploy, which means you can only publish the latest tip of the latest branch. This prevents us from having separate API references for each branch/MR/tag. I've only seen GitLab CI used to deploy artifacts to S3 buckets, so I don't know if we can rsync CI build artefacts to some place on the
gnome.org infrastructure (I'd rather avoid involving an S3 bucket, at this point, unless we can afford it for the future); it's something that the GNOME sysadmins would need to investigate/set up. Publishing build artefacts has the added bonus that we could finally get rid of the release tarballs for projects, and just generate the dist archive when pushing a (signed) tag, thus removing a pain point from the maintainers plate—but that has nothing to do with the documentation.
Emmanuele.
