Re: [RFC] Detailing a service transition plan for glibc to CTI for August 2026.
Mark Wielaard <[email protected]> Sun, 2 Aug 2026 20:53:00 +0200
| Newsgroups | gmane.comp.lib.glibc.alpha |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Jul 28, 2026 at 12:43:27AM +0200, Zoë Kooyman via Overseers wrote: > August is coming up soon, and given the push of yet another draft > proposal to move some glibc services, we are compelled to > respond to the discussions around the hosting of glibc once > again to get critical about the current proposal: > https://sourceware.org/glibc/wiki/service-transition-plan. Note that this draft plan seems to have been retracted and no longer planned for August after the reviews in https://sourceware.org/bugzilla/show_bug.cgi?id=34384 raised issues with trust, privacy, timeline, acceptance criteria and missing action items required for such a transition. So this is a good oppertunity to discuss alternatives. The official Sourceware Project Leadership statement on the original draft proposal is below. We have reviewed the proposed migration plans, and have found no technical need for overseer consent or assistance. As we have said before, FOSS projects are welcome to come, stay, and leave sourceware. Proposers of this idea already have all the data/access required. However, to avoid perceptions of privacy violation, we strongly suggest securing affirmative consent for each piece of user PII (addresses, names, ssh credentials) that proposers wish to copy to a new hosting system. Given the partial nature of this proposed transition (git + mailing list stuff only, leaving everything else on sourceware with only "TODO" integration plans), and the possibility of a later return, we don't foresee having to disable or remove anything, so those community members wishing to continue using sourceware services/mirrors can do so. As an alternative to a disruptive migration, other sourceware hosting options previously offered still remain available, including a customized gitolite setup, or the forge, or even a whole dedicated VM. Other projects on sourceware are using each of them already. They could be welcomed by members of the community who expressed concerns about the current proposal. The plan so far does not include anything that sourceware doesn't already or couldn't easily provide.