Siddhesh Poyarekar via Overseers writes:
>> what
>> alternatives we have, etc.
> For projects the alternatives they have are:
>
> 1. Migrate to LF IT infrastructure
> 2. Have a presence on sourceware as well as LF IT, contingent to Red
> Hat's decision on the hardware infrastructure
> 3. Stay fully on sourceware
>
> For sourceware as infrastructure the alternatives are:
>
> 1. Migrate to LF IT infrastructure
> 2. Stay as it currently is
>
> For sourceware overseers, the choices are contingent on what projects
> decide and what Red Hat decides w.r.t. sourceware.
>
> All of the above has been clear all along. Maybe the problem here is
> that you're not happy with the alternatives?
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/.
For example, at FSF tech team (where I work), we jointly maintain
services with many volunteers that volunteer for specific projects. They
are mainly: KDE, Linux Libre, Emacs, Savannah, Guix, GNU debbugs,
replicant, h-node.org, planet.gnu.org, and Trisquel. The FSF tech team
keeps a 24 hour on call rotation, so the services have a dedicated ops
team to fix issues and respond to alerts, but the day to day management
of the services those groups want, eg: upgrading them, configuring,
modifying, etc is mostly done by volunteers.
To give some very specific examples: a group of volunteer sysadmins for
emacs decided they wanted a new build service for Emacs, so they jumped
in a meeting with FSF tech team (I'm part of it) to discuss all the
technical details and requirements. We decided the volunteers would do
the primary installation and management of a gitlab that was only
configured to use the build server, and FSF tech team would setup
alerts, create the VM and the DNS. We agree on what kind of uptime is
expected and what kind of alerts the tech team will respond to in off
hours. The volunteer's ssh keys sit alongside the FSF tech team's keys
on that VM. Alternatively, for Trisquel, Trisquel orders hardware and we
go install it to the data center, and the Trisquel sysadmins spin up
their own virtual machines or whatever they want to run, we just go into
the data center with spare parts and fix things if the hardware breaks
down. For any service we are going to support, we learn enough about the
service to fix things things.
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.
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 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.
--
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org
