Re: Core Toolchain Infrastructure - Services for glibc

[Florian Weimer <fweimer@redhat.com>]

* Konstantin Ryabitsev:

> 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.

That's good to know.

>> > * 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.

Okay, so there are options, good.

>> 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.

One way to deal with this on our end would be a policy that allows
branch rebases to pull faulty commits for a time.  Lately we have pushed
some misformatted commit messages in the current setup, with its commit
hooks.

Thanks,
Florian