Meeting Minutes - Office Hours for CTI - 2026-08-28

[Zack Weinberg]

On Tue, Sep 8, 2026, at 5:33 PM, Joseph Myers wrote:
> On Tue, 8 Sep 2026, Alexandre Oliva wrote:
>
>> Our current voluntary hosting arrangements listen to and participate in
>> the community.  If we want to try something out, they're normally happy
>> to lend us a hand and make it happen.
>> 
>> A professional hosting arrangement will involve a professional
>> relationship, in which only designated parties will be able to submit
>> requests in order to have them as much as listened to.
>> 
>> This is not AT ALL in the best interest of the community.
>
> As far as possible, configuration changes for production infrastructure 
> *should* be slow and carefully considered

While I do think this is the best way, don't you see that it also applies to
the changes on the table?  In particular, *starting* a hosting switch by
moving -- not mirroring -- the two most critical services (git and email),
which are also the two services most difficult to move, and most difficult
to roll back if something goes wrong, strikes me as incredibly unwise,
regardless of all other considerations.

> rather than just happening 
> because one community member thought a change was a good idea and one 
> hosting person then implemented it, possibly disrupting things for other 
> people, deviating from a previous community consensus or introducing a 
> security vulnerability.

I feel like you and Alexandre are imagining different things.  Are you aware
of changes made on a "sure why not, sounds like a good idea to me" basis
*to critical production services specifically*, rather than more experimental
things like the patch tracker and the wiki?

> The current hosting arrangements also have their own variant of the 
> "synchronous meeting" problem - unless you happen to be on #overseers at 
> the time a particular change gets suggested, discussed and implemented, 
> you never know about the change or have a chance to give input until you 
> see it break something.  I think a slower, more formal system can *also* 
> have better community input than at present by moving as many discussions 
> of hosting changes as possible to libc-alpha

Fully agreed here.

> after, of course, there is 
> better isolation of infrastructure so it's genuinely possible for glibc to 
> decide what's wanted independently of other projects currently hosted on 
> the same system.

However, I don't see why this has to come first.  Moving the conversations and
arranging for better isolation are almost entirely uncoupled -- the only catch
is that a conversation about a shared service might need to be cc:ed to more
mailing lists.

zw