Re: New Website Repositories

From: Sam Darwin (samuel.d.darwin_at_[hidden])
Date: 2024-02-16 20:49:53

> Is there a reason

Also, the django project is deployed to a container, and then scaled to
multiple servers, automatically with github actions. That should be as
streamlined as possible, and doesn't need to have a large amount of extra
files. The temp-site-documentation ... could perhaps be moved to the
boost-tasks repo, or another place.    So it's fine to not merge for the
time being.

On Fri, Feb 16, 2024 at 1:41 PM Vinnie Falco via Boost <
boost_at_[hidden]> wrote:

> On Fri, Feb 16, 2024 at 12:33 PM Glen Fernandes
> <glen.fernandes_at_[hidden]> wrote:
> > If you want to follow the tradition of source files, the easiest
> > convention to follow is to state that your files, e.g.
> >
> >     <!--
> >     Copyright (c) 2024 <author>
> >     Distributed under the Boost Software License, Version 1.0.
> >     See accompanying file LICENSE_1_0.txt or copy at
> >     http://www.boost.org/LICENSE_1_0.txt
> >     -->
>
> We can do that, or alternatively is it possible to just plop a LICENSE
> file at the root of the repository?
>
> > Is there a reason the contribution cannot be a single (mono) repository?
>
> This might be possible in theory but is not a good idea. When changes
> are made to the develop version of the website proper, it is built and
> staged at a separate URL so that it can be quality-controlled before
> going live. When a pull request is submitted to documentation
> repository ("site-docs", which holds the User Guide, Contributor's
> Guide, and Boost Formal Review Process manual), there is a complex
> backend process which rebuilds the static pages for the documentation,
> publishes it to a temporary S3 bucket, and then through a GitHub API
> replies to the pull request with a link to a preview of the resulting
> changes.
>
> If we make this all into a single repository, then every time a pull
> request or change is made to this mono-repo, we might have to settle
> for rebuilding literally everything. To prevent that would require
> analyzing the changes, and so on.... maybe possible, but considerable
> work in exchange for just having fewer repos. This doesn't sound like
> a win.
>
> We can probably move the documentation for the website into the
> "site-docs" repo. To be clear, this is not end-user documentation
> regarding the libraries, this is documentation for the website itself.
> That is, the structure of the database, how the various cloud
> instances and services are deployed, and so on. As Sam is the author
> of that documentation, I would leave that up to him.
>
> Thanks
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>