Re: Action: Setup working group for the GNU Toolchain proposal to migrate to LF IT managed services

On 11/21/22 15:49, Joseph Myers wrote:
> 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.

I wasn't aware that Bugzilla could accept posts by email (I personally
don't use it).  I am also unaware of any local Bugzilla changes.  Like I
said in the meeting, I never touched at the infrastructure, I just know
it as a "black box" user.

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

Ok, maybe I misunderstood the point of the list then.  I thought it was
a list of functional requirements, what needs to work from a user point
of view, regardless of how it's implemented.

[Implementation detail: I know about the email-to-bugzilla script,
because Joel sent it to me lately.  I am in the process of rewriting it
in Python (if it's in Perl, I just can't contribute, sorry) to make it
recognize bugzilla URLs in commit messages.  The script accesses the DB
directly just to see if a given bug number exists.  If Bugzilla has a
proper REST interface, it should be easy to change.]

I'll go over the list again, see if I can add some details, but it
certainly won't be in as much details as what Carlos did.

Simon