From: Joseph Myers <joseph@codesourcery.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Carlos O'Donell <carlos@redhat.com>, <gti-tac@lists.linuxfoundation.org>
Subject: Re: Action: Setup working group for the GNU Toolchain proposal to migrate to LF IT managed services
Date: Mon, 21 Nov 2022 20:49:24 +0000 [thread overview]
Message-ID: <da126be7-475f-e2ed-fb4f-4493271db5f3@codesourcery.com> (raw)
In-Reply-To: <Y3rxAYa/oc5s/R/7@adacore.com>
On Mon, 21 Nov 2022, Joel Brobecker wrote:
> * bug tracker (bugzilla)
I think this needs to go into more details. Details of incoming email
handling (some Bugzilla installations don't use incoming email, we need to
be explicit about how it's a key feature used in our installations),
details of outgoing email handling, details of local changes to the
Bugzilla installation and how account creation is handled, for example.
> - /sourceware/infra/bin/email-to-bugzilla
>
> Sends a copy of commit messages to bugzilla if commit
> has a PR number in it.
The fact that this currently seems to use SQL access to the database is a
really important thing to include in the list of services. Remember that
we're trying for more isolation of components with minimal interfaces
between them, to improve security. So if this script could be changed or
rewritten to use the (public) REST interface instead of SQL access to
check for whether bugs exist, that would be helpful. (The fact that it
sends email to add to Bugzilla is also relevant, because it means that any
system running this script needs to be able to send email - and for any
system sending email, it will be necessary to avoid losing outgoing email
if it's a transient system and there's a transient email problem.)
In general, details of exactly what interfaces are used by components to
interact with others - especially if they make any assumptions about
direct database or filesystem access, or about different services being
hosted on the same system - are really important. (This would then give a
list of cases where we should *change* the interfaces used to remove such
dependencies - for example, using the public read-only REST API to extract
information from Bugzilla instead of SQL access.)
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2022-11-21 20:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 17:24 Action: Setup working group for the GNU Toolchain proposal to migrate to LF IT managed services Carlos O'Donell
2022-11-11 23:36 ` Joseph Myers
2022-11-15 19:42 ` Carlos O'Donell
2022-11-15 20:25 ` Joel Brobecker
2022-11-17 14:10 ` Simon Marchi
2022-11-21 3:31 ` Joel Brobecker
2022-11-21 3:32 ` Joel Brobecker
2022-11-21 20:49 ` Joseph Myers [this message]
2022-12-05 17:45 ` David Edelsohn
2022-12-12 4:44 ` Joel Brobecker
2022-12-06 15:52 ` Simon Marchi
2022-12-06 17:42 ` Simon Marchi
2022-12-06 17:43 ` David Edelsohn
2022-12-24 5:31 ` Joel Brobecker
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=da126be7-475f-e2ed-fb4f-4493271db5f3@codesourcery.com \
--to=joseph@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=carlos@redhat.com \
--cc=gti-tac@lists.linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.