Re: Migration to CTI services should be an opportunity to reduce dependency on git hooks.

On 6/21/24 9:30 AM, Frank Ch. Eigler wrote:
>> The gcc community was locked out of committing because of
>> issues with the AdaCore hooks: [...]
>> My strong opinion, particularly for glibc is that we have as
>> few hooks as possible, and timeout those remote hooks in a
>> reasonable amount of time.
> 
> Note that these hooks exist only at the pleasure and control of each
> individual project.

To the degree that these hooks don't impact other services though.

The hooks themselves use resources, so we need to have a design discussion
with the community when that community needs custom hooks:

 * what is required
 * what is desirable
 * what can we do to improve security and isolation
 * how can we design a system that degrades gracefully
 
etc. 
 
>> As we transition the services we should be looking to architect
>> a safe and robust system that can handle the hooks timing out [...]
> > You don't have to wait - such a thing can be prototyped today.

We're tackling glibc today and doing just that as we transition to CTI services.

> Is the issue mainly the lack of anyone's time to do that?

We will get to it as part of CTI services since it's in the SOW scope?

For gcc, binutils and gdb we could engage to gather more exact requirements
from the developers doing the day-to-day work e.g. what features did we really
need from the AdaCore hooks.

Then scope out the solution and what it looks like, and a prototype would
certainly go a long way to giving a good budget estimate.

Then figure out deployment and cost e.g. small vm to run the isolated hook
that returns a result, average timeout, and degraded result e.g. no bugzilla
data.

Then the usual TAC review, vote, and approve the spend (unless already covered
under the budget).

Would you be interested in working on this for the gcc hooks?

-- 
Cheers,
Carlos.