public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
* Re: Proposing Sourceware as SFC member project
       [not found] <Yw5aTCLyYx8qqN3W@wildebeest.org>
@ 2022-08-31 22:19 ` Jose E. Marchesi
  2022-09-01  8:28   ` Mark Wielaard
  0 siblings, 1 reply; 19+ messages in thread
From: Jose E. Marchesi @ 2022-08-31 22:19 UTC (permalink / raw)
  To: overseers


> If you have an interest in the long term future of the sourceware
> hosting server which this project is using, please consider checking
> out this thread on our local overseers@ mailing list.  Everything is
> fine, we're just thinking ahead.
>
> https://sourceware.org/pipermail/overseers/2022q3/018802.html
>
> Chris Faylor <cgf@sourceware.org>
> Frank Eigler <fche@sourceware.org>
> Mark Wielaard <mark@klomp.org>

Do you plan to publish the application text before actually starting the
process?  If so, where can it be found?  Where can it be discussed, in
case people have comments/suggestions?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Proposing Sourceware as SFC member project
  2022-08-31 22:19 ` Proposing Sourceware as SFC member project Jose E. Marchesi
@ 2022-09-01  8:28   ` Mark Wielaard
  2022-09-02 18:51     ` Daniel Pono Takamori
  0 siblings, 1 reply; 19+ messages in thread
From: Mark Wielaard @ 2022-09-01  8:28 UTC (permalink / raw)
  To: Overseers mailing list
  Cc: Jose E. Marchesi, Daniel Pono Takamori, Bradley M. Kuhn

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Hi Jose,

On Thu, Sep 01, 2022 at 12:19:59AM +0200, Jose E. Marchesi via Overseers wrote:
> > If you have an interest in the long term future of the sourceware
> > hosting server which this project is using, please consider checking
> > out this thread on our local overseers@ mailing list.  Everything is
> > fine, we're just thinking ahead.
> >
> > https://sourceware.org/pipermail/overseers/2022q3/018802.html
> 
> Do you plan to publish the application text before actually starting the
> process?  If so, where can it be found?  Where can it be discussed, in
> case people have comments/suggestions?

The full text of the application is attached. The process is fairly
informal https://sfconservancy.org/projects/apply/ We had some
informal chats about the idea some months ago to see if applying even
made sense to them. Luckily they were enthousiastic. You are then
requested to supply your formal application in plain text form more
like a story than a Q/A form. The attached full text leaves out the
parts that didn't make sense to a pure hosting project like
sourceware. I believe sourceware is the first pure free software
hosting project that is applying, so it is also somewhat new to
them. You are then requested to be as transparent as possible with the
community so people can make suggestions and nobody is caught by
surprise. Which is the step we are at now. Then they'll sent the
application to the SFC evaluation committee which must approve
https://sfconservancy.org/about/eval-committee/ We should hear before
Cauldron whether or not we were accepted.

I CCed Daniel and Bradley from the Conservancy to correct any mistakes
in my description of the procedures.

Cheers,

Mark

[-- Attachment #2: apply-conservancy.txt --]
[-- Type: text/plain, Size: 7037 bytes --]


Sourceware provides hosting to essential free software toolchain
projects using only free software and in a way that the developers
themselves are in control. It can be seen as alternative to
proprietary hosting platforms, but has existed long before free
software project hosting became a business. It tries to enable
developers to be in control of their own hosting.

We don't have an immediate need for fiscal sponsorship, but we want to
be ready when we do. We hope Conservancy can be our partner when in
the future we do need an independent (non-profit, public benefit)
party to hold assets or enter into contracts. For example if we do
want to hire someone to do some basic admin stuff or we decide we want
to have some cloud machines. If we want to crowdfund funds to contract
some additions to projects like buildbot, patchwork or sourcehut on
which we rely.

Conservancy seems like a good pick for a fiscal sponsor since it has a
strong commitment to Software Freedom, community and public
interest. We also believe we would be a good partner to Conservancy by
offering hosting to toolchain related projects, for example to those
projects wanting to migrate off github. We also rely on various
projects which are already Conservancy member projects and can and
will upstream any of the improvements we are making to those.

Sourceware is mainly known for hosting the GNU Toolchain projects, gcc
at https://gcc.gnu.org/, glibc, binutils and gdb. But also hosts
projects like annobin, bunsen, bzip2, cgen, cygwin at
https://cygwin.org/, debugedit, dwz, elfutils at http://elfutils.org,
gccrs, gnu-abi, insight, kawa, libffi, libabigail, mauve, newlib,
systemtap and valgrind at https://valgrind.org/.

A longer list of projects Sourceware supports, those without their own
domain names, including several dormant projects, can be found here:
https://sourceware.org/mailman/listinfo.  Projects hosted by
Sourceware are mostly lower level toolchain related.  Projects can
come and go as their needs change.

Not all projects use all of the services Sourceware offers. Although
various projects share services on sourceware, projects are free to
tweak or adjust services as needed. Most projects aren't simply
"consumers" of the Sourceware provided infrastructure but active
participants.

Our main challenge is the fact that most sourceware communities use an
email based workflow, which has been working great for them but isn't
always welcoming to newcomers. The following URL provides a roadmap to
making email/git based workflow more fun, secure and productive by
automating contribution tracking and testing across different distros
and architectures using buildbot, bunsen, patchwork, public-inbox and
possibly sourcehut:

https://sourceware.org/pipermail/overseers/2022q2/018529.html

If we would raise funds through Conservancy we would try to find a way
to support our current efforts to extend the services we offer. This
could be contract negotiation for some basic admin stuff or additions
to projects like bugzilla, buildbot, patchwork or sourcehut. These
activities have no specific geographic place.

Funds aren't the most important/crucial for Sourceware. The important
part is expanding the active overseers and/or project admins.

The project has no trademarks. Sourceware was used first by Cygnus
Solutions in 1994 as an alternative term for Free Software before
adopting the term Open Source. See http://www.toad.com/gnu/cygnus

The project uses a green variant of the public domain Copleft sign
https://en.wikipedia.org/wiki/Copyleft#/media/File:Copyleft.svg

It used as favicon and is on various of our pages/services:
https://sourceware.org/img/GreenCopyleft.svg
https://sourceware.org/img/logo_big2.png
 
sourceware.cygnus.com was established in 1998 by Cygnus to host
various GNU projects Cygnus contributed to and Cygwin (which later got
its own cygwin.org domain, but shared hosting with Sourceware). In
1999 it was merged with gcc.gnu.org as the developer controlled
hosting side for GCC. In 2000 after Cygnus merged with Red Hat it was
briefly renamed to sources.redhat.com till in 2001 Ian Lance Taylor
registed sourceware.org and it became an independent hosting
project. Red Hat still provides hardware and network connectivity
through https://osci.io/ but does not involve itself with the actual
running of the project.

Sourceware has a very flexible governance structure. There is a group
of overseers (basically those people with root access to the main
hosting server) who can create new user accounts for projects. Of
these overseers there are three people who do the day to day
maintenance (Frank, Chris and Mark), who can be considered the
Sourceware representatives.

Projects hosted by Sourceware do not need to contribute or participate
in the infrastructure services, but most do. For example Overseers
grant access to project specific accounts to install cronjobs or git
hooks, grant admin permissions to bugzilla or other services. In
general projects define their own rules on who gets accounts and
permissions for manipulating their services which Overseers follows.

There have been no major disputes. In general we have had enough
resources to provide any service projects have asked for. And we don't
hold projects hostage and will help them if they want to (partially)
migrate to another hosting service.

As a hosting project you could say that all our offerings are Software
as a Service. All services are offered to all project and they are all
based on Free Software. We try to use packaged software as much as
possible and try to upstream any patches we make. If possible (and if
we remember) we try to document the setup too for others to replicate
locally to make contributing to the service as easy as possible. See
e.g our buildbot service which has its full configuration in a git
repo with full documentation on how to setup and hack on a local copy:
https://sourceware.org/git/?p=builder.git;a=tree

Red Hat's OSCI https://osci.io/, provides hardware and network
connectivity for our main hosting server. We get additional build
servers from OSUOSL, Marist University, Brno University, IBM, Arm and
a handful of individuals. All servers are maintained by volunteers,
either by the Sourceware overseers or project maintainers. We prefer
these informal relationships as long as the developers are in control
of the provided hardware. Even when Conservancy becomes the fiscal
sponsor for Sourceware we would like to keep this informal
sponsorships in place. So we don't think it would work if Conservancy
becomes the exclusive way to sponsor Sourceware with resources.

Accross all projects hosted by Sourceware we have ~1250 user
(developer) accounts. The shared bugzilla database lists ~13500 users
(this excludes GCC which has its own bug database). We have more than
200 mailinglists some with a handful, some with hundreds or even a
thousand subscribers.

Here is an image of all our contributors/hosted projects from 2019
https://sourceware.org/img/sourceware.png

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Proposing Sourceware as SFC member project
  2022-09-01  8:28   ` Mark Wielaard
@ 2022-09-02 18:51     ` Daniel Pono Takamori
  2022-09-03 14:07       ` Karen M. Sandler
  0 siblings, 1 reply; 19+ messages in thread
From: Daniel Pono Takamori @ 2022-09-02 18:51 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Overseers mailing list, Jose E. Marchesi, Bradley M. Kuhn

Mark Wielaard wrote yesterday today:
> I CCed Daniel and Bradley from the Conservancy to correct any mistakes
> in my description of the procedures.

Thanks, Mark, your summary of SFC's processes are basically correct.
What I'd like to add is that we've already pointed SFC's Evaluation
Committee to this thread — and we're confident they will all review the
discussion here as part of the evaluation of Sourceware for membership
and fiscal sponsorship by SFC.

Organizationally, we believe in transparency by default for FOSS
projects, and this is even more important for community decision making.
We encouraged Sourceware to discuss their application publicly. 

Almost ten years ago (before my time), SFC participated in a discussion
with the VertX project (and many others) when VertX was choosing a
non-profit fiscal sponsor:
https://groups.google.com/g/vertx/c/WIuY5M6RluM/m/LC_6WkTaQN0J

We learned from that experience (and other similar experiences) that
public discussion on a project's mailing list about the options
available for fiscal sponsorship, and frank discussion by the project's
leadership about what fiscal sponsorship organization best fits their
needs as a project are essential. These days there are *so many* great
options for fiscal sponsorship. There are for-profit
fiscal-sponsorship-as-a-service companies like OpenCollective. There are
corporate-business-interest-focused trade association fiscal sponsors
like Eclipse (where VertX ultimately ended up). Then, there are
charities like SFC. All these options exist because projects' needs and
culture differ. We think fiscal sponsorship sign-up is the best time for
a FOSS community to do some identity-searching and figure out what
organizational structure best fits their project culture. When
governance hasn't been explicitly defined, these growing experiences are
the times when communities need to reflect and embed their values into
their governance structure. And, in a true FOSS way, we believe this
should be done in public, community discussion.

We also post an FAQ for projects (or other fiscal sponsors looking for
information) that are considering applying:
https://sfconservancy.org/projects/apply/ In particular you can review
the standard fiscal sponsorship agreement (FSA) that we use
https://sfconservancy.org/docs/sponsorship-agreement-template.pdf that
might give you a better sense of the kind of governance and fiscal/
legal oversight we provide. SFC's interest in this regard is to preserve
the creation of free software with free software tools and to preserve
community driven development. Please let me know if you have any
questions or are curious about the differences between SFC and other
fiscal sponsors.

Sincerely,
Pono, Community Organizer at Software Freedom Conservancy

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Proposing Sourceware as SFC member project
  2022-09-02 18:51     ` Daniel Pono Takamori
@ 2022-09-03 14:07       ` Karen M. Sandler
  2022-09-03 16:38         ` Mark Wielaard
  2022-09-18 19:42         ` Moving sourceware to the Linux Foundation? No thanks Christopher Faylor
  0 siblings, 2 replies; 19+ messages in thread
From: Karen M. Sandler @ 2022-09-03 14:07 UTC (permalink / raw)
  To: Daniel Pono Takamori
  Cc: Mark Wielaard, Overseers mailing list, Jose E. Marchesi, Bradley M. Kuhn

Pono wrote:
   > These days there are *so many* great options for fiscal sponsorship.

+1, SFC has really been thrilled to see so many organizations build 
fiscal sponsorship programs. People tend to think because SFC was one of 
the early fiscal sponsors in FOSS that we view the other ones as 
"competitors". In fact, we frequently point projects to other 
organizations that could be a better fit. We like a transparent, public 
discussion by projects to pick the fiscal sponsor that fits them best.

In that vein, since this thread was started, we have received 
communication from a couple of people telling us that there was also a 
proposal for an application related to Sourceware with the Linux 
Foundation for fiscal sponsorship. We're glad to hear it because we 
*always* encourage applicants to SFC to also simultaneously apply to 
other fiscal sponsors in parallel, as a method to vet and evaluate the 
various options.

I and my staff will be monitoring this thread to answer questions on 
SFC's behalf, and presume that LF folks will do the same. We look 
forward to the discussion, particularly because we love discussion of 
the different ways that organizations accomplish fiscal sponsorship, and 
part of our mission is educating the FOSS community about non-profit 
governance options. And perhaps an entirely different approach might 
emerge from multiple organizations working together that hasn't even 
been thought of yet.

In any case, I'm excited to see the future for this important free 
software hosting project!



Karen M. Sandler
Executive Director, Software Freedom Conservancy
__________
Become a Sustainer today! http://sfconservancy.org/sustainer/


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Proposing Sourceware as SFC member project
  2022-09-03 14:07       ` Karen M. Sandler
@ 2022-09-03 16:38         ` Mark Wielaard
  2022-09-18 19:42         ` Moving sourceware to the Linux Foundation? No thanks Christopher Faylor
  1 sibling, 0 replies; 19+ messages in thread
From: Mark Wielaard @ 2022-09-03 16:38 UTC (permalink / raw)
  To: Karen M. Sandler
  Cc: Daniel Pono Takamori, Overseers mailing list, Jose E. Marchesi,
	Bradley M. Kuhn

Hi Karen,

On Sat, Sep 03, 2022 at 10:07:29AM -0400, Karen M. Sandler wrote:
> I and my staff will be monitoring this thread to answer questions on SFC's
> behalf, and presume that LF folks will do the same. We look forward to the
> discussion, particularly because we love discussion of the different ways
> that organizations accomplish fiscal sponsorship, and part of our mission is
> educating the FOSS community about non-profit governance options. And
> perhaps an entirely different approach might emerge from multiple
> organizations working together that hasn't even been thought of yet.
> 
> In any case, I'm excited to see the future for this important free software
> hosting project!

Thanks so much for your guidance and excitement. It is great seeing
the non-profit organizations working together so well. That is
especially important for a free software hosting project like
Sourceware because we host both little and big projects. Some with
their own fiscal sponsor, some without any funding at all. Being able
to share non-profit organisation resources and services is a great
thing to look forward to.

Thanks,

Mark

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Moving sourceware to the Linux Foundation? No thanks.
  2022-09-03 14:07       ` Karen M. Sandler
  2022-09-03 16:38         ` Mark Wielaard
@ 2022-09-18 19:42         ` Christopher Faylor
  2022-09-25 22:31           ` Mark Wielaard
  1 sibling, 1 reply; 19+ messages in thread
From: Christopher Faylor @ 2022-09-18 19:42 UTC (permalink / raw)
  To: overseers

Just a heads up to the people reading this list:

A couple of GNU project affiliated folks have been soliciting the Linux
Foundation to "take over" sourceware.  The talks have been going on in
relative secrecy for more than a year.  The project is officially
mentioned here:

https://linuxfoundation.org/join-project/

(search for GNU toolchain)

This proposal is for more than the fiscal sponsorship offered by the
SFC, as seen in the overseers mailing list.  The SFC proposal keeps the
current sourceware infrastructure and administration while offering
opportunities for fiscal sponsorship to help fund new sourceware
infrastructure projects.

The LF proposal, on the other hand, is for a wholesale move of the
sourceware domain and services to a system wholly owned and controlled
by Linux Foundation IT.

I can't personally support the LF plan and, if the move happens as it's
being proposed, will no longer be contributing my time to sourceware.

I did endorse this move to the LF when I first heard about it in April
but I've since withdrawn that support and removed myself from the "GTI"
team which you can see at the project page above.  My reasons:

0) It is dubious to me that the organizers have the authority to
represent "sourceware" or even their own communities in any official
capacity.

1) The non-public, compartmentalized approach employed by the organizers
for gaining what they call "consensus" seemed to be counter to the
way things are usually handled in FOSS projects.

Until very recently, the organizers seemed to be intent on minimizing
public disclosure and discussion of this endeavor until they can make a
big reveal.  To me, that seems wrong for something this important.
Moving sourceware is a huge deal and I think there should be *public*
discussion with as many people as possible.

2) Private email to select individuals seemed to focus on only the "GNU"
people who use sourceware even though project-count-wise GNU/FSF
projects are in the minority here.

Popular projects like Cygwin were not represented in these private
discussions even though the Cygwin project would be severely impacted by
any move.  I guess that makes sense for a "GNU Toolchain Initiative" but
it doesn't make sense when you're talking about moving *all* projects
hosted by sourceware.org to a differently (and more restrictively) run
platform.

3) LF IT's proposal for how services would be provided to this new
platform seemed questionable.

IMO, if the move happens, we'd be giving up too much autonomy.
Administrative decisions would require a committee vote, asking LF IT
for a statement of work.  I think that is guaranteed to add frustrating
red tape and delay.

Sourceware could also be forced to use proprietary software for things
like mailing lists - which is something that should be an anathema to
FOSS projects.

I was also not confident that LF IT would be dedicated to a seamless,
minimum-downtime transition.  I think there could be a noticeable impact
on project development during any sourceware transition.

                                ---

If you're satisfied in the way sourceware has been run and are confident
that the people running it know what they're doing, and have your best
interests at heart, then please speak up.  If you don't really know
what's going on here and don't want to take my word for it that
something smells fishy then *please* listen carefully to to the proposal
if/when this is finally publicly announced.  I would not be surprised if
alarms start going off in your head when you hear what's being proposed
- like they did for me.

For those who don't know, I've been helping keep sourceware running
since I was at Cygnus (and then Red Hat) starting in 1999.  I've
continued to offer my volunteer services since I left Red Hat in 2003.

cgf


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-18 19:42         ` Moving sourceware to the Linux Foundation? No thanks Christopher Faylor
@ 2022-09-25 22:31           ` Mark Wielaard
  2022-09-26 14:07             ` Ian Lance Taylor
  2022-09-26 22:21             ` Moving sourceware to the Linux Foundation? No thanks Carlos O'Donell
  0 siblings, 2 replies; 19+ messages in thread
From: Mark Wielaard @ 2022-09-25 22:31 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Christopher Faylor

Hi Chris,

On Sun, Sep 18, 2022 at 03:42:38PM -0400, Christopher Faylor via Overseers wrote:
> The LF proposal, on the other hand, is for a wholesale move of the
> sourceware domain and services to a system wholly owned and controlled
> by Linux Foundation IT.

We talked a bit at the Cauldron about it and agreed to continue the
conversation on this list. There is somewhat of an overview of the
plan in this lwn article:
https://lwn.net/SubscriberLink/908638/567de0001d86662c/

I hope they will post the whole proposal to this list, but I think it
really is a couple of separate proposals. Each proposal is connected
to the LF or a subsidiary which makes it sound like it is one big LF
takeover. It was kind of presented as a package deal, but I think we
can mix and match the separate proposals once we better understand the
separate parts. Also different parts seem to have the same or similar
names "GTI", which sometimes seem to stand for GNU Toolchain
Initiative or GNU Toolchain Infrastructure. I'll try to explain as far
as I understand it.

First there is a proposal from the LF/OpenSSF to provide money to help
with solving certain cybersecurity requirements. Some of these seem to
be related to actual infrastructure requirements, others seem to be
related to project policies around using signed commits and patch
attestation and following things like https://slsa.dev/

It wasn't really clear which security issue was really an
infrastructure issue. I tried to separate some concerns in this email:
https://sourceware.org/pipermail/overseers/2022q3/018849.html

The LF/OpenSSF has a ten point plan:
https://openssf.org/oss-security-mobilization-plan/

Some of which do seem interesting, but will need a lot of work to turn
into concrete things we can do with the infrastructure and policies to
adapt for the projects.

I think for concrete infrastructure related ideas the Conservancy
could accept the money and we can decide how to use it to implement
them.

Secondly they would like to setup a fund at the Linux Foundation which
would collect money from sponsors. This is (also) called GTI. These
sponsors then decide how to spend their money to best help the GNU
Toolchain (which seems to extend to all Sourceware projects).

This LF/GTI would then hire the LF/IT to provide some managed services
for some sourceware projects.

Another idea was to use the fund to setup a BBB server. It wasn't
clear whether the LF/IT would then also be asked to set that up.

Finally they would setup an advisory board, which advises the LF/IT
how to run the managed services and which would also have one seat on
the LF/GTI for spending money on other initiatives.

It isn't completely clear yet how all this mixes-and-matches with
Sourceware being a Conservancy member project. But I think we should
be able to figure out how to combine the best parts of the community
driven approach with the corporate sponsor approach once more details
become clear.

> If you're satisfied in the way sourceware has been run and are confident
> that the people running it know what they're doing, and have your best
> interests at heart, then please speak up.  If you don't really know
> what's going on here and don't want to take my word for it that
> something smells fishy then *please* listen carefully to to the proposal
> if/when this is finally publicly announced.  I would not be surprised if
> alarms start going off in your head when you hear what's being proposed
> - like they did for me.
> 
> For those who don't know, I've been helping keep sourceware running
> since I was at Cygnus (and then Red Hat) starting in 1999.  I've
> continued to offer my volunteer services since I left Red Hat in 2003.

I am really sorry your huge influence on Sourceware wasn't more
prominently mentioned during the BoF.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-25 22:31           ` Mark Wielaard
@ 2022-09-26 14:07             ` Ian Lance Taylor
  2022-09-26 17:05               ` Christopher Faylor
                                 ` (2 more replies)
  2022-09-26 22:21             ` Moving sourceware to the Linux Foundation? No thanks Carlos O'Donell
  1 sibling, 3 replies; 19+ messages in thread
From: Ian Lance Taylor @ 2022-09-26 14:07 UTC (permalink / raw)
  To: Overseers

I see two important points that ought to be discussed on this topic.

The first is succession planning.  Sourceware is essentially a community
project with a relatively small number of people keeping it going.  It
needs trusted and capable people to step it to continue to maintain it.
Where are those people going to come from?  We shouldn't simply hope
that it will keep carrying on as before.

The second, mentioned in Mark's e-mail, is security.  I hope that we can
all agree that there are highly intelligent, highly motivated people
seeking to break security on GNU/Linux and other free operating systems.
Years ago Ken Thompson laid out the roadmap for attacking an operating
system via the compiler and other code generation tools.  These days
these are known as supply chain attacks.  I think that the free software
community should reasonably insist that sourceware be defended against
these kinds of attacks with mechanisms for prevention and detection and
restoration.  This is a hard job.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-26 14:07             ` Ian Lance Taylor
@ 2022-09-26 17:05               ` Christopher Faylor
  2022-09-26 19:57               ` Frank Ch. Eigler
  2022-09-26 21:53               ` Moving sourceware into the future Mark Wielaard
  2 siblings, 0 replies; 19+ messages in thread
From: Christopher Faylor @ 2022-09-26 17:05 UTC (permalink / raw)
  To: overseers

On Mon, Sep 26, 2022 at 07:07:20AM -0700, Ian Lance Taylor wrote:
>I see two important points that ought to be discussed on this topic.
>
>The first is succession planning.  Sourceware is essentially a community
>project with a relatively small number of people keeping it going.  It
>needs trusted and capable people to step it to continue to maintain it.
>Where are those people going to come from?  We shouldn't simply hope
>that it will keep carrying on as before.

The "GTI" debacle has shown fche, mjw, and me that there needs to be
some way to formalize the management of sourceware.  I think that the
SFC proposal helps with that since we will need some sort of official
governing board when we move forward.  Those people should be a hedge
against the hit-by-a-bus problem.

Personally, I feel more comfortable with a group of formalized
volunteers who will presumably listen to input than with a corporate
entity which dictates what (sometimes non-free) software *must* be used
to adhere to their corporate guidelines.

"You want a mailing list?  Sure! That will be $157.  We'll have it for
you in about six weeks and it *will* be groups.io."

>The second, mentioned in Mark's e-mail, is security.  I hope that we can
>all agree that there are highly intelligent, highly motivated people
>seeking to break security on GNU/Linux and other free operating systems.
>Years ago Ken Thompson laid out the roadmap for attacking an operating
>system via the compiler and other code generation tools.  These days
>these are known as supply chain attacks.  I think that the free software
>community should reasonably insist that sourceware be defended against
>these kinds of attacks with mechanisms for prevention and detection and
>restoration.  This is a hard job.

It's a hard job but I think it is only partly sourceware's job.  We can
provide the tools and guidance, but it has got to be up to the projects
(gcc, glibc, cygwin) to implement the protocols which enhance security.

One thing we've talked about is hiring someone to do a security audit
once sourceware has some funding.

cgf


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-26 14:07             ` Ian Lance Taylor
  2022-09-26 17:05               ` Christopher Faylor
@ 2022-09-26 19:57               ` Frank Ch. Eigler
  2022-09-27 13:03                 ` Carlos O'Donell
  2022-09-28  8:33                 ` Ian Kelling
  2022-09-26 21:53               ` Moving sourceware into the future Mark Wielaard
  2 siblings, 2 replies; 19+ messages in thread
From: Frank Ch. Eigler @ 2022-09-26 19:57 UTC (permalink / raw)
  To: overseers; +Cc: ian

Hi -

> I see two important points that ought to be discussed on this topic.

Thanks for joining the discussion.

> The first is succession planning.  Sourceware is essentially a community
> project with a relatively small number of people keeping it going.  It
> needs trusted and capable people to step it to continue to maintain it.
> Where are those people going to come from?  We shouldn't simply hope
> that it will keep carrying on as before.

Fair, we need to attend to recruiting more helpers.  (It was with this
in mind that some folks got root on sourceware in the last few years.)
With some moderate funding, the small amount of IT effort this place
requires could be filled out with talented part-timers.  OTOH, it's
not an emergency, and the system is not complicated, running
off-the-shelf basic RHEL8 for the core stuff (git, mail, mailing
lists, http, ssh, authentication).


> The second, mentioned in Mark's e-mail, is security.  I hope that we
> can all agree that there are highly intelligent, highly motivated
> people seeking to break security on GNU/Linux and other free
> operating systems.  [...]  sourceware be defended against these
> kinds of attacks with mechanisms for prevention and detection and
> restoration.  [...]

Luckily, sourceware is a pure upstream source repo, ships no binaries,
and holds no secrets.  As long as the integrity of the data is assured
(for example by some mixture of crypto signed git-everything, broad
backups of the git data, and project reviewers/maintainers doing their
jobs), I don't think Thompson's hypothetical attack can be effective.
Certainly, suggestions to improve infrastructure stability /
resilience would be welcome, but it seems like projects can already
self-serve code-repo security, if they choose to.


- FChE


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware into the future
  2022-09-26 14:07             ` Ian Lance Taylor
  2022-09-26 17:05               ` Christopher Faylor
  2022-09-26 19:57               ` Frank Ch. Eigler
@ 2022-09-26 21:53               ` Mark Wielaard
  2022-09-27 17:12                 ` Daniel Pono Takamori
  2 siblings, 1 reply; 19+ messages in thread
From: Mark Wielaard @ 2022-09-26 21:53 UTC (permalink / raw)
  To: overseers; +Cc: Ian Lance Taylor

Hi Ian,

On Mon, Sep 26, 2022 at 07:07:20AM -0700, Ian Lance Taylor via Overseers wrote:
> The first is succession planning.  Sourceware is essentially a community
> project with a relatively small number of people keeping it going.  It
> needs trusted and capable people to step it to continue to maintain it.
> Where are those people going to come from?  We shouldn't simply hope
> that it will keep carrying on as before.

Yes! This is admittedly an important reason of why we are joining the
Conservancy as a member project. We are at the point in the process
where we will have to form a PLC (Project leadership committee). This
will initially be some of the active overseers, some emiritus and
representatives of the hosted projects who help out with the
infrastructure. One part of their job is making sure the plc itself
and the overseers get refreshed from time to time. Another part is
selecting paid contractors where necessary. One of the Conservancy
services is "Leadership Mentoring, Advice and Guidance" where we can
ask other project leaders how to effectively deal with this.

I also found that publishing these public roadmaps really helped
attracting more people. People spontaniously contacted me if they
could help with some setup of something we hadn't gotten to yet. Or
they offered resources to make a service better. And Frank's idea of
having a specific "meta" Sourceware bugzilla component also already
seems to pay off with people looking at what Sourceware needs and
picking up issues to work on. Not all these people will become active
overseers or join the PLC, but I already feel better about attracting
new talent.

> The second, mentioned in Mark's e-mail, is security.  I hope that we can
> all agree that there are highly intelligent, highly motivated people
> seeking to break security on GNU/Linux and other free operating systems.
> Years ago Ken Thompson laid out the roadmap for attacking an operating
> system via the compiler and other code generation tools.  These days
> these are known as supply chain attacks.  I think that the free software
> community should reasonably insist that sourceware be defended against
> these kinds of attacks with mechanisms for prevention and detection and
> restoration.  This is a hard job.

Again yes! Although the largest part of defending against "supply
chain attacks" depends on project policy changes, like whether to
adopt signed commits as Ulrich suggested on the gcc list recently:
https://gcc.gnu.org/pipermail/gcc/2022-September/239450.html
Or adopting some form of patch attestation like I had wanted to
discuss in the Cauldron BoF:
https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide17
(see also the slides before and some of the presenter notes by
pressing 'p' if you have javascript enabled)

One issue with defending against "supply chain" or having a
"cybersecurity" plan is that it means different things to different
people. Which makes it hard to have a good threat-model. Without which
you cannot really make sure you "defended" against anything.

Although I think the slsa method https://slsa.dev/ is way too involved
and heavy-weight for most projects to adopt I thought they made a good
analysis of the different supply chain threats and how to protect
against them: https://slsa.dev/spec/v0.1/threats

For us only the source integrity threats are applicable:
https://slsa.dev/spec/v0.1/threats#source-integrity-threats

Where roughly "(A) Submit unauthorized change" threads are project
policy issues (but which the hosting platform should support). And
"(B) Compromise source repo" are hosting platform issues.

There are also https://slsa.dev/spec/v0.1/threats#availability-threats
which can be solved with more mirroring.

One nice property of us doing everything openly an publicly is that we
generally don't have to defend against leaking "secrets". And if you
make sure that (proposed) code changes can be verified or attested by
the actual developers then if you have mirrors (easy for git, now
possible for the mailinglist through our public-inbox setup) then even
if one host gets compromised you will still be able to check the whole
"supply chain" against a mirror or your local copy.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-25 22:31           ` Mark Wielaard
  2022-09-26 14:07             ` Ian Lance Taylor
@ 2022-09-26 22:21             ` Carlos O'Donell
  1 sibling, 0 replies; 19+ messages in thread
From: Carlos O'Donell @ 2022-09-26 22:21 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Mark Wielaard, Christopher Faylor

On 9/25/22 18:31, Mark Wielaard via Overseers wrote:
> Hi Chris,
> 
> On Sun, Sep 18, 2022 at 03:42:38PM -0400, Christopher Faylor via Overseers wrote:
>> The LF proposal, on the other hand, is for a wholesale move of the
>> sourceware domain and services to a system wholly owned and controlled
>> by Linux Foundation IT.
> 
> We talked a bit at the Cauldron about it and agreed to continue the
> conversation on this list. There is somewhat of an overview of the
> plan in this lwn article:
> https://lwn.net/SubscriberLink/908638/567de0001d86662c/
> 
> I hope they will post the whole proposal to this list, but I think it
> really is a couple of separate proposals. Each proposal is connected
> to the LF or a subsidiary which makes it sound like it is one big LF
> takeover. It was kind of presented as a package deal, but I think we
> can mix and match the separate proposals once we better understand the
> separate parts. Also different parts seem to have the same or similar
> names "GTI", which sometimes seem to stand for GNU Toolchain
> Initiative or GNU Toolchain Infrastructure. I'll try to explain as far
> as I understand it.

GTI stands for GNU Toolchain Infrastructure.

I agree that there is some mixing-and-matching that we can do, and that we already
do today to a certain degree.

> First there is a proposal from the LF/OpenSSF to provide money to help
> with solving certain cybersecurity requirements. Some of these seem to
> be related to actual infrastructure requirements, others seem to be
> related to project policies around using signed commits and patch
> attestation and following things like https://slsa.dev/

Correct, along with that the OpenSSF has as a technical vision, making secure development
practices the norm.

> It wasn't really clear which security issue was really an
> infrastructure issue. I tried to separate some concerns in this email:
> https://sourceware.org/pipermail/overseers/2022q3/018849.html

I've responded to your post there to discuss a few more points.

> The LF/OpenSSF has a ten point plan:
> https://openssf.org/oss-security-mobilization-plan/
> 
> Some of which do seem interesting, but will need a lot of work to turn
> into concrete things we can do with the infrastructure and policies to
> adapt for the projects.
> 
> I think for concrete infrastructure related ideas the Conservancy
> could accept the money and we can decide how to use it to implement
> them.
> 
> Secondly they would like to setup a fund at the Linux Foundation which
> would collect money from sponsors. This is (also) called GTI. These
> sponsors then decide how to spend their money to best help the GNU
> Toolchain (which seems to extend to all Sourceware projects).
> 
> This LF/GTI would then hire the LF/IT to provide some managed services
> for some sourceware projects.
> 
> Another idea was to use the fund to setup a BBB server. It wasn't
> clear whether the LF/IT would then also be asked to set that up.
> 
> Finally they would setup an advisory board, which advises the LF/IT
> how to run the managed services and which would also have one seat on
> the LF/GTI for spending money on other initiatives.
> 
> It isn't completely clear yet how all this mixes-and-matches with
> Sourceware being a Conservancy member project. But I think we should
> be able to figure out how to combine the best parts of the community
> driven approach with the corporate sponsor approach once more details
> become clear.

Two proposals.

The first is that we would seek fiscal sponsorship from the OpenSSF at the Linux
Foundation because they are specifically looking to solve secure supply chain
issues and many of us would like to see that improved for the core GNU Toolchain
and other projects. This involves setting up project, the GNU Toolchain Infrastructure
project, and discussing with sponsors to support the project. There is a structure
to GTI which we can discuss in another thread (board, TAC, community etc.)

The second is that we would migrate to managed services at the Linux Foundation IT.
I've highlighted in the other thread why I think this is the best technical choice, but
I'll copy it here:
~~~
Technically speaking, I think the Linux Foundation IT, with their existing work with
public-inbox (ahead of its time), b4, patatt, and more, means they are globally the
best positioned to keep solving these problems and supporting the development of
these FOSS tools for the linux kernel and others. Even more so for a distributed
development model that we use for the GNU Toolchain.
~~~

>> If you're satisfied in the way sourceware has been run and are confident
>> that the people running it know what they're doing, and have your best
>> interests at heart, then please speak up.  If you don't really know
>> what's going on here and don't want to take my word for it that
>> something smells fishy then *please* listen carefully to to the proposal
>> if/when this is finally publicly announced.  I would not be surprised if
>> alarms start going off in your head when you hear what's being proposed
>> - like they did for me.
>>
>> For those who don't know, I've been helping keep sourceware running
>> since I was at Cygnus (and then Red Hat) starting in 1999.  I've
>> continued to offer my volunteer services since I left Red Hat in 2003.
> 
> I am really sorry your huge influence on Sourceware wasn't more
> prominently mentioned during the BoF.

I also really appreciate Chris' efforts and support.

Thank you again Chris.

-- 
Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-26 19:57               ` Frank Ch. Eigler
@ 2022-09-27 13:03                 ` Carlos O'Donell
  2022-09-28  8:53                   ` Ian Kelling
  2022-09-28  8:33                 ` Ian Kelling
  1 sibling, 1 reply; 19+ messages in thread
From: Carlos O'Donell @ 2022-09-27 13:03 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Frank Ch. Eigler

On 9/26/22 15:57, Frank Ch. Eigler via Overseers wrote:
> Hi -
> 
>> I see two important points that ought to be discussed on this topic.
> 
> Thanks for joining the discussion.
> 
>> The first is succession planning.  Sourceware is essentially a community
>> project with a relatively small number of people keeping it going.  It
>> needs trusted and capable people to step it to continue to maintain it.
>> Where are those people going to come from?  We shouldn't simply hope
>> that it will keep carrying on as before.
> 
> Fair, we need to attend to recruiting more helpers.  (It was with this
> in mind that some folks got root on sourceware in the last few years.)
> With some moderate funding, the small amount of IT effort this place
> requires could be filled out with talented part-timers.  OTOH, it's
> not an emergency, and the system is not complicated, running
> off-the-shelf basic RHEL8 for the core stuff (git, mail, mailing
> lists, http, ssh, authentication).

I think it's more than just recruiting more helpers.

Succession planning means taking Ian's comment seriously, planning out the costs
if the volunteers don't show up, and making sure there is funding in place for
projected costs.

It's a hard problem because tracking down funding is hard, and estimation is also
hard.
 
>> The second, mentioned in Mark's e-mail, is security.  I hope that we
>> can all agree that there are highly intelligent, highly motivated
>> people seeking to break security on GNU/Linux and other free
>> operating systems.  [...]  sourceware be defended against these
>> kinds of attacks with mechanisms for prevention and detection and
>> restoration.  [...]
> 
> Luckily, sourceware is a pure upstream source repo, ships no binaries,
> and holds no secrets.  As long as the integrity of the data is assured
> (for example by some mixture of crypto signed git-everything, broad
> backups of the git data, and project reviewers/maintainers doing their
> jobs), I don't think Thompson's hypothetical attack can be effective.
> Certainly, suggestions to improve infrastructure stability /
> resilience would be welcome, but it seems like projects can already
> self-serve code-repo security, if they choose to.

(a) Today - Shipping binary artifacts.

Where are the Cygwin windows binaries hosted?

For example: https://cygwin.com/setup-x86_64.exe

(b) Tomorrow - Shipping binary artifacts.

There might be a future where we want to ship cross-tooling directly for the
GNU Toolchain to make it easier, like djgpp did, to bring FOSS to an ever expanding
and wider audience.

Even if we don't ship binaries, shipping source tarballs also might be of interest
(currently only shipped via the GNU Project repositories).

-- 
Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware into the future
  2022-09-26 21:53               ` Moving sourceware into the future Mark Wielaard
@ 2022-09-27 17:12                 ` Daniel Pono Takamori
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Pono Takamori @ 2022-09-27 17:12 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Mark Wielaard

Thanks for the thoughtful comments on project structure and future planning.
I've added some thoughts inline below.

On Mon, Sep 26, 2022 at 11:53:14PM +0200, Mark Wielaard via Overseers wrote:
> Hi Ian,
> 
> On Mon, Sep 26, 2022 at 07:07:20AM -0700, Ian Lance Taylor via Overseers wrote:
> > The first is succession planning.  Sourceware is essentially a community
> > project with a relatively small number of people keeping it going.  It
> > needs trusted and capable people to step it to continue to maintain it.
> > Where are those people going to come from?  We shouldn't simply hope
> > that it will keep carrying on as before.
> 
> Yes! This is admittedly an important reason of why we are joining the
> Conservancy as a member project. We are at the point in the process
> where we will have to form a PLC (Project leadership committee). This
> will initially be some of the active overseers, some emiritus and
> representatives of the hosted projects who help out with the
> infrastructure. One part of their job is making sure the plc itself
> and the overseers get refreshed from time to time. Another part is
> selecting paid contractors where necessary. One of the Conservancy
> services is "Leadership Mentoring, Advice and Guidance" where we can
> ask other project leaders how to effectively deal with this.

Helping create and maintain is a really important part of the relationship
between SFC and our member projects. Like everyone pointed out the
"bus factor" is an important consideration for governance. Making sure
that there is a robust group of people with varying backgrounds and
skills makes project healthiers.

Also as pointed out, working with contractors is another part of our
bread and butter. Managing funds, both in fundraising and spending,
is one of the core features of having a fiscal sponsor and something
we take very seriously. As noted previously, finding some contractors
to work on security related issues sounds like a high priority task, so
we can help allocate those funds and work with you to find the
appropriate people to get the work done.

> I also found that publishing these public roadmaps really helped
> attracting more people. People spontaniously contacted me if they
> could help with some setup of something we hadn't gotten to yet. Or
> they offered resources to make a service better. And Frank's idea of
> having a specific "meta" Sourceware bugzilla component also already
> seems to pay off with people looking at what Sourceware needs and
> picking up issues to work on. Not all these people will become active
> overseers or join the PLC, but I already feel better about attracting
> new talent.


I've seen a lot of talk about "open governance" recently, and I think
technical and governance roadmaps are a great place to start!
Once a governance team/ plan has been created, outside people
are much more likely to want to participate since they'll know the
rough structure of the project. It's so hopeful to hear that there are
people interested in volunteering and helping the project out!

> > The second, mentioned in Mark's e-mail, is security.  I hope that we can
> > all agree that there are highly intelligent, highly motivated people
> > seeking to break security on GNU/Linux and other free operating systems.
> > Years ago Ken Thompson laid out the roadmap for attacking an operating
> > system via the compiler and other code generation tools.  These days
> > these are known as supply chain attacks.  I think that the free software
> > community should reasonably insist that sourceware be defended against
> > these kinds of attacks with mechanisms for prevention and detection and
> > restoration.  This is a hard job.
> 
> Again yes! Although the largest part of defending against "supply
> chain attacks" depends on project policy changes, like whether to
> adopt signed commits as Ulrich suggested on the gcc list recently:
> https://gcc.gnu.org/pipermail/gcc/2022-September/239450.html
> Or adopting some form of patch attestation like I had wanted to
> discuss in the Cauldron BoF:
> https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide17
> (see also the slides before and some of the presenter notes by
> pressing 'p' if you have javascript enabled)
> 
> One issue with defending against "supply chain" or having a
> "cybersecurity" plan is that it means different things to different
> people. Which makes it hard to have a good threat-model. Without which
> you cannot really make sure you "defended" against anything.
> 
> Although I think the slsa method https://slsa.dev/ is way too involved
> and heavy-weight for most projects to adopt I thought they made a good
> analysis of the different supply chain threats and how to protect
> against them: https://slsa.dev/spec/v0.1/threats
> 
> For us only the source integrity threats are applicable:
> https://slsa.dev/spec/v0.1/threats#source-integrity-threats
> 
> Where roughly "(A) Submit unauthorized change" threads are project
> policy issues (but which the hosting platform should support). And
> "(B) Compromise source repo" are hosting platform issues.
> 
> There are also https://slsa.dev/spec/v0.1/threats#availability-threats
> which can be solved with more mirroring.
> 
> One nice property of us doing everything openly an publicly is that we
> generally don't have to defend against leaking "secrets". And if you
> make sure that (proposed) code changes can be verified or attested by
> the actual developers then if you have mirrors (easy for git, now
> possible for the mailinglist through our public-inbox setup) then even
> if one host gets compromised you will still be able to check the whole
> "supply chain" against a mirror or your local copy.

I won't speak to any of the technical or infrastructural points about
security, but to say that we leave those choices up to our projects and
support them however they see fit. Also hopefully there are some free
software options in the burgeoning "software supply chain" and artifact
verification spaces, as it's becoming increasingly clear that there are
some open questions in those areas.

Let me know if you have any questions,
-Pono on behalf of Software Freedom Conservancy

> 
> Cheers,
> 
> Mark

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-26 19:57               ` Frank Ch. Eigler
  2022-09-27 13:03                 ` Carlos O'Donell
@ 2022-09-28  8:33                 ` Ian Kelling
  2022-09-28 10:08                   ` Frank Ch. Eigler
  1 sibling, 1 reply; 19+ messages in thread
From: Ian Kelling @ 2022-09-28  8:33 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Frank Ch. Eigler


"Frank Ch. Eigler via Overseers" <overseers@sourceware.org> writes:

> Hi -
>
>> I see two important points that ought to be discussed on this topic.
>
> Thanks for joining the discussion.
>
>> The first is succession planning.  Sourceware is essentially a community
>> project with a relatively small number of people keeping it going.  It
>> needs trusted and capable people to step it to continue to maintain it.
>> Where are those people going to come from?  We shouldn't simply hope
>> that it will keep carrying on as before.
>
> Fair, we need to attend to recruiting more helpers.  (It was with this
> in mind that some folks got root on sourceware in the last few years.)
> With some moderate funding, the small amount of IT effort this place
> requires could be filled out with talented part-timers.  OTOH, it's
> not an emergency, and the system is not complicated, running
> off-the-shelf basic RHEL8 for the core stuff (git, mail, mailing
> lists, http, ssh, authentication).

There is already a built in succession plan you all seem to be ignoring.
GNU already separately hosts most of same infrastructure that sourceware
does. If sourceware volunteers all stepped down tomorrow, GNU would be
ready to immediately step up and host servers, maintain services,
recruit new volunteers, and that effort would likely be lead by FSF
sysadmin staff like me. There are currently 3 tech team members,
https://www.fsf.org/about/staff-and-board there's been about that many
for a long time, like a decade now, and we aren't going anywhere . GNU
infrastructure is a large part of every FSF tech team member's job that
we do full time. If you want to make succession plans, we should be part
of that planning.

-- 
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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-27 13:03                 ` Carlos O'Donell
@ 2022-09-28  8:53                   ` Ian Kelling
  2022-10-02 21:15                     ` Mark Wielaard
  0 siblings, 1 reply; 19+ messages in thread
From: Ian Kelling @ 2022-09-28  8:53 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Carlos O'Donell


Carlos O'Donell via Overseers <overseers@sourceware.org> writes:

> On 9/26/22 15:57, Frank Ch. Eigler via Overseers wrote:

> Even if we don't ship binaries, shipping source tarballs also might be of interest
> (currently only shipped via the GNU Project repositories).

I'm on of the FSF tech team members that maintains the GNU Project
repositories, eg: https://ftp.gnu.org/pub/gnu/gcc/ . If you have any
problems or improvement you want to that hosting, talk to us. There is
no reason for hosting to be changed or duplicated elsewhere. FSF can
actually host a lot more things and this seems to have been overlooked
when discussing potential changes to sourceware hosting.

 I'm now watching this list, so talking here is fine. If you want to
email us privately, sysadmin@fsf.org (sysadmin@gnu.org goes to the same
place).

You can read about the FSF tech team here,
https://www.fsf.org/about/staff-and-board and out blog posts
https://www.fsf.org/blogs/sysadmin/


-- 
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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-28  8:33                 ` Ian Kelling
@ 2022-09-28 10:08                   ` Frank Ch. Eigler
  0 siblings, 0 replies; 19+ messages in thread
From: Frank Ch. Eigler @ 2022-09-28 10:08 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Ian Kelling

Hi -

> There is already a built in succession plan you all seem to be ignoring.
> GNU already separately hosts most of same infrastructure that sourceware
> does. If sourceware volunteers all stepped down tomorrow, GNU would be
> ready to immediately step up and host servers, maintain services,
> recruit new volunteers, and that effort would likely be lead by FSF
> sysadmin staff like me. [...]

Excellent point.

In case an emergency occurred, there exists a pool of people who would
certainly jump into help.  Depending on the nature of the problem,
with documented SOPs, someone could step in in situ.  For a simple
service like sourceware, it's not rocket science.  In extremis,
restart things from distributed backups.  The essentials of sourceware
content are already exposed for duplication (source repositories,
email archives, release tarballs).


- FChE

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Moving sourceware to the Linux Foundation? No thanks.
  2022-09-28  8:53                   ` Ian Kelling
@ 2022-10-02 21:15                     ` Mark Wielaard
  0 siblings, 0 replies; 19+ messages in thread
From: Mark Wielaard @ 2022-10-02 21:15 UTC (permalink / raw)
  To: Overseers mailing list; +Cc: Ian Kelling

Hi Ian,

On Wed, Sep 28, 2022 at 04:53:15AM -0400, Ian Kelling via Overseers wrote:
> I'm on of the FSF tech team members that maintains the GNU Project
> repositories, eg: https://ftp.gnu.org/pub/gnu/gcc/ . If you have any
> problems or improvement you want to that hosting, talk to us. There is
> no reason for hosting to be changed or duplicated elsewhere. FSF can
> actually host a lot more things and this seems to have been overlooked
> when discussing potential changes to sourceware hosting.
> 
>  I'm now watching this list, so talking here is fine. If you want to
> email us privately, sysadmin@fsf.org (sysadmin@gnu.org goes to the same
> place).

Thanks. Although the various GNU projects of course do use the GNU ftp
services which requires cryptographically signed releases. Other
Sourceware projects don't enforce that.

I'll file an sourceware infrastructure bug to see if we can provide
something similar to
https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads
for the other Sourceware projects. I assume the scripts for that are
available somewhere.

Also it might be nice to have cross-mirrors between sourceware and
gnu.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Proposing Sourceware as SFC member project
       [not found] <Yw5btfOsg6EJRvsM@wildebeest.org>
@ 2022-09-05 15:51 ` Thomas Fitzsimmons
  0 siblings, 0 replies; 19+ messages in thread
From: Thomas Fitzsimmons @ 2022-09-05 15:51 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: overseers

Hi Mark,

Mark Wielaard <mark@klomp.org> writes:

> If you have an interest in the long term future of the sourceware
> hosting server which this project is using, please consider checking
> out this thread on our local overseers@ mailing list.  Everything is
> fine, we're just thinking ahead.
>
> https://sourceware.org/pipermail/overseers/2022q3/018802.html

This proposal looks good to me.  It seems like a good idea that
sourceware.org have a way to receive donations.  The ongoing continuous
integration and patch management improvements will likely make
sourceware.org services desirable to more Free and Open Source software
projects.

Thomas

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-10-02 21:15 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <Yw5aTCLyYx8qqN3W@wildebeest.org>
2022-08-31 22:19 ` Proposing Sourceware as SFC member project Jose E. Marchesi
2022-09-01  8:28   ` Mark Wielaard
2022-09-02 18:51     ` Daniel Pono Takamori
2022-09-03 14:07       ` Karen M. Sandler
2022-09-03 16:38         ` Mark Wielaard
2022-09-18 19:42         ` Moving sourceware to the Linux Foundation? No thanks Christopher Faylor
2022-09-25 22:31           ` Mark Wielaard
2022-09-26 14:07             ` Ian Lance Taylor
2022-09-26 17:05               ` Christopher Faylor
2022-09-26 19:57               ` Frank Ch. Eigler
2022-09-27 13:03                 ` Carlos O'Donell
2022-09-28  8:53                   ` Ian Kelling
2022-10-02 21:15                     ` Mark Wielaard
2022-09-28  8:33                 ` Ian Kelling
2022-09-28 10:08                   ` Frank Ch. Eigler
2022-09-26 21:53               ` Moving sourceware into the future Mark Wielaard
2022-09-27 17:12                 ` Daniel Pono Takamori
2022-09-26 22:21             ` Moving sourceware to the Linux Foundation? No thanks Carlos O'Donell
     [not found] <Yw5btfOsg6EJRvsM@wildebeest.org>
2022-09-05 15:51 ` Proposing Sourceware as SFC member project Thomas Fitzsimmons

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).