On Wed, 20 Feb 2019 at 17:27, Petr Kovar wrote:
> > 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.
Ciao,
Emmanuele.
--
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
