public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Siddhesh Poyarekar <siddhesh@gotplt.org>,
	 Florian Weimer <fweimer@redhat.com>,
	Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>,
	 Carlos O'Donell <carlos@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>,
	 "Ryan S. Arnold" <ryan.arnold@gmail.com>,
	Paul Eggert <eggert@cs.ucla.edu>,
	 Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	Andreas Schwab <schwab@suse.de>
Subject: Re: Core Toolchain Infrastructure - Services for glibc
Date: Tue, 18 Jul 2023 09:38:40 -0400	[thread overview]
Message-ID: <20230718-reshuffle-backlight-7f220c@meerkat> (raw)
In-Reply-To: <ZLaFBGygP/n+uFY9@tucnak>

On Tue, Jul 18, 2023 at 02:26:44PM +0200, Jakub Jelinek wrote:
> > This would mean porting AdaCore hooks to a patchwork trybot.  This would be
> > an acceptable solution for glibc, but I'm not sure how useful this would be
> > on the whole since gcc doesn't use patchwork as extensively at the moment.
> > Also, we need to figure out who's going to do this.
> 
> It is definitely not acceptable for gcc, we strongly rely on server side
> pre-commit hooks for various different tasks.

I'm not saying "no hooks at all," but the general rule is:

- a hook can run checks on the contents of the commit message
- a hook can query external systems for validation results (with a reasonably
  short timeout)

The core principle is that hooks should be fast and shouldn't have a large
attack surface, because hooks are running with full access to the underlying
repository. Any CI builds or other validations should run prior to the push
and visible to the committer before the push is attempted. I mention patchwork
because it's a system we use, but other options exist (e.g. gerrit, though
I wouldn't use it just for CI purposes).

Regards,
-K

  parent reply	other threads:[~2023-07-18 13:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 21:58 Carlos O'Donell
2023-07-14 11:38 ` Florian Weimer
2023-07-14 15:34   ` Konstantin Ryabitsev
2023-07-18 11:47     ` Siddhesh Poyarekar
2023-07-18 12:26       ` Jakub Jelinek
2023-07-18 13:19         ` Jeff Law
2023-07-18 13:24           ` Siddhesh Poyarekar
2023-07-20 17:43           ` Joseph Myers
2023-07-18 13:38         ` Konstantin Ryabitsev [this message]
2023-08-03 10:10     ` Florian Weimer
2023-07-14 15:58 ` Mark Wielaard
2023-08-22 15:53 ` Frank Ch. Eigler
2023-08-23  7:57   ` Sourceware Infrastructure " Mark Wielaard
2023-08-29 20:45   ` Core Toolchain Infrastructure - " Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230718-reshuffle-backlight-7f220c@meerkat \
    --to=konstantin@linuxfoundation.org \
    --cc=carlos@redhat.com \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=ryan.arnold@gmail.com \
    --cc=schwab@suse.de \
    --cc=siddhesh@gotplt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).