All: The contribution of a brand new, mostly complete website at the level of quality of what we at The C++ Alliance have developed (see https://preview.boost.org) is a rare event. We are proud to share this special moment in Boost history. As is the Boost tradition we propose to do the following: * Transfer of all website related repositories to the Boost GitHub organization (these will also be renamed to something sensible): https://github.com/cppalliance/temp-site https://github.com/cppalliance/temp-site-documentation https://github.com/cppalliance/site-docs https://github.com/cppalliance/boost-mailman ...plus any other miscellaneous necessary repositories that Sam has created for the administration of the website, mailing list, and release process. * Whatever is the appropriate license for the artwork to be used on the website, with copyright to "The C++ Alliance, Inc. (https://cppalliance.org)" With respect to the artwork licensing, I have to admit I am not an expert so we will work to find out what the proper solution is. Thanks
On Fri, Feb 16, 2024 at 3:27 PM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
As is the Boost tradition we propose to do the following:
* Transfer of all website related repositories to the Boost GitHub organization (these will also be renamed to something sensible):
https://github.com/cppalliance/temp-site https://github.com/cppalliance/temp-site-documentation https://github.com/cppalliance/site-docs https://github.com/cppalliance/boost-mailman ...plus any other miscellaneous necessary repositories that Sam has created for the administration of the website, mailing list, and release process.
Before we accept any contribution (including transfer of repository, as is the case when a library that passes review gets transferred to us) it has to be licensed under the BSL. 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 --> Is there a reason the contribution cannot be a single (mono) repository? Glen
On Fri, Feb 16, 2024 at 12:33 PM Glen Fernandes <glen.fernandes@gmail.com> 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
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@lists.boost.org> wrote:
On Fri, Feb 16, 2024 at 12:33 PM Glen Fernandes <glen.fernandes@gmail.com> 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
participants (3)
-
Glen Fernandes -
Sam Darwin -
Vinnie Falco