Re: Core Toolchain Infrastructure - Services for glibc

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Fri, Jul 14, 2023 at 01:38:00PM +0200, Florian Weimer wrote:
> >  * Support public-inbox for mailing list archives.
> >  * Use of public-inbox means archives can be cloned and copied.
> >  * Use of LF IT Subspace mailing list services (mlmmj, postfix).
> 
> I assume LF IT is able to run mailing lists without “via” From:
> rewriting?

Yes, that practice is horrible and we do not support it in any way shape or
form for mailing lists.

> > * bug database
> >  * Consider starting fresh in new Bugzilla 5.0.4+ instance and freeze old product.
> >  * glibc component in sourceware instance marked "Not open for new bugs."
> >  * No easy way to clone this but we can discuss options.
> >  * Isolate bugzilla from other services.
> 
> Does LF IT offer some Bugzilla anti-spam services?  To what extent do we
> need to constrain new sign-ups?

We have various approaches here, depending on the project.

We do not constrain sign-ups for bugzilla.kernel.org. We have a script that
reports new comments containing links or potentially spammy attachments. These
comments are junked and accounts posting them are banned.

We do constrain sign-ups for bugzilla.yoctoproject.org -- users must request a
new account to be created before they can file any bugs.

> Can we keep using the AdaCore hooks?  Or would they have to run on the
> side somehow?  Who is going to implement changes to the AdaCore scripts?

This is the main point of contemplation -- we do not currently support custom
hooks on the server side:

- they tend to significantly slow down pushes
- they run extensive codebases with the same permissions as the owner of the
  repositories, significantly increasing security risks

Our recommendation was to move all CI tasks to a system that is better suited
for it. For example, CI can run on a patchwork system and the pre-commit hook
can then check that each commit matches a patchwork entry that passed CI.

> > * wiki
> >  * Migrate to git-based documentation with existing content copied over.
> >  * Suggest rst/Sphinx or similar to existing discussions for GCC docs.
> >  * Sphinx with themes can provide a lot of flexibility for display.
> >  * Isolate wiki service from other services.
> 
> Will this be a separate Git repository, with different commit rules?
> 
> I do not particularly like the current MoinMoin wiki, but at least it
> has a preview button.  We'd lose that with a pure Git-based workflow.

RTD documentation is written in ReST, for which there are many editors that
provide preview functionality.

-K