On 2022-10-23 04:59, Ian Kelling wrote:
No, I don't think that was ever clear. I've just read this message, but
I've been keeping up with everything public since Cauldron. All your
options assume that any specific service is 100% managed by LF IT, or
100% managed by sourceware. That is a bad assumption. They could do it
together, or another group could help. So, you said you wanted
"dedicated ops management", and I assume sourceware is not currently
equipped for that. But there is no reason that an ops team from LF IT or
FSF could not provide dedicated ops management for existing sourceware
services in collaboration with sourceware. Another notable ops team is
OSU, https://osuosl.org/.
Hybrid administration isn't part of the GTI proposal, why would that be
considered an option? Is this something you'd like to propose to the
TAC, i.e. give named members from the community access to infrastructure
administration? We can bring that up in our discussion with the LF IT.
Anyways, basically, having a dedicated ops team does not imply removing
the sourceware's role, it could simply mean: adding a dedicated ops team
to sourceware.
Given that the current sourceware admins have decided to block migration
of all sourceware assets to the LF IT, I don't have a stake on how
they'd like to handle this for sourceware. I could however, as a member
of TAC (and as member of projects that have agreed to migrate to LF IT,
i.e. gcc and glibc), discuss with others the possibility of specific
community volunteers being given some amount of access to manage
infrastructure.
To provide dedicated ops for the physical servers would require moving
the servers or into servers in a data center near the ops team, or
outsourcing the hardware management to one of many companies (usually by
renting a physical server), but that is all totally feasible and not a
big cost.
Siddhesh Poyarekar via Overseers <overse...@sourceware.org> writes:
I want us to migrate
services to infrastructure with better funding (that's not just limited
to services),
What do you want to fund specifically? "Infrastructure" and "not limited
to services" is not specific enough to understand.
and an actually scalable future.
What does "an actually scalable future" mean? That is very vague.
Both of those point to scaling hardware in addition to services, having
things like physical isolation of services. Scaling volunteers (which
hasn't happened in the last 20-soemthing years; it has scaled *down*, if
anything) and money to pay for dedicated ops isn't going to mostly
pointless if we can't pay for hardware, which is owned by Red Hat.
That, and FSF not being able to add resources for the GNU toolchain was
in fact why we had to look elsewhere for funding.
I suggest you wait a day for the FSF hosted call so that the background
is clearer.
Sid
