GTI TAC Meeting Notes 2022-11-09

GTI TAC Meeting Notes 2022-11-09

[Carlos O'Donell]

GTI TAC Meeting Notes 2022-11-09

Meeting URL: https://8x8.vc/gti-infrastructure/gti-tac
- Using FOSS Jitsi hosted by 8x8's Meet service.
- No scalability issues.
- Jose had video issues.

IRC on OFTC #gti-tac.

Technical issues:
- Unable to login to 8x8's systems and authenticate as moderator
  - Timeout from sign-on systems.
- Unable to "record" the meeting, instead Carlos took quick notes
  on the discussion as it happened. These notes are inaccurate
  or even misleading, please take them with a grain of salt and
  reply to correct them if required :-)

Agenda:
The agenda for the GTI TAC meeting would be to
discuss the next steps for the current proposal:
the GNU Toolchain moving to managed infrastructure
at the LF IT. We could additionally discuss some of
the mechanics of the TAC, like where we'll put our
documents, notes

Present:
Joseph Myers
Jose Marchesi
Nick Clifton
Siddhesh Poyarekar
Frank Ch. Eigler
David Edelsohn
Simon Marchi
Carlos O'Donell

Regrets:
Joel Broebecker

Agenda:
- Discussing the mechanics of TAC documents.
 - git site / read-the-docs or sphinx
 - Get access to TAC for that.
   - ssh keys for gitolite
 - Domain for the GTI.
 - Joseph notes gti-tac.org is available
 - David suggests using a more general domain
 - Jose notes is this for all of the projects or just GTI
 - Carlos notes that this would be for GTI
 - Ask LF IT to set that up.
- TAC mechanics
 - Simon: Could we use this domain for services?
 - David: There is a distinction here between GTI and the
   services GTI offers.
 - David: Have a number of domains:
   - Have gnutoolchain.org
   - Have gnutools.org
 - David: There is a longer discussion about trademark for GNU
 - Siddhesh: Could we just use some of the LF and OpenSSF stuff?
 - David: Some of that could be non-FOSS
 - Siddhesh: Do we have concerns about non-FOSS for the TAC?
 - David: Yes.
 - Siddhesh: Yes, a simple solution would work.
 - David: Also have.
   - toolchains.dev
   - tollchain-infrastructure.org
- Regarding the GNU Toolchain infrastrucutre at the LF IT proposal
 - Next steps?
 - Create a working group.
 - Detailed assessment of the current technoloyg and services.
   - Enumerate the features.
 - Wether the GTI TAC or subgroup, working with the LF IT
 - Use the more detailed list to do the analysis and sizing
   of effort and expense for:
   - Steady state provisioning of the services.
   - Transitioning the services.
 - With that plan and budget, the GTI TAC votes on that.
 - Plan goes out for review.
 - Jose: Do I have your permission to be a little bit naive here.
   - The GNU Toolchain projects are GNU projects.
   - The projects have had a historical process.
   - How do we make that decision?
 - Carlos: That would be for the GNU Toolchain projects to decide that.
 - David: Yes, this needs to go out to those projects to make their decisions.
 - Jose: That's clear.
 - Siddhesh: Yes, there is a bit of word soup here. The "Leadership" is the
   general term here because multiple projects use different nomenclature.
 - Joseph: Details of LF services.
   - Each of the individual cron jobs run by gccadmin
   - What do those services do.
   - What are their inputs and ouputs.
   - Similarly we need to understand which ways the git hooks come in and out.
   - Anonymous rsync.
   - Readonly svn, cvs.
   - Misc. legacy.
   - Scripts that update regression markers via direct SQL access.
 - David: Completely agree with you Joseph.
 - Carlos: Before changing the topic. Jose did we answer that topic?
 - Jose: Yes, just raising this because of controversy and a desire for clarity.
 - Carlos: Absolutely, that makes sense. More clarity is good.
 - David: A concrete step. Consensus of next steps?
   - Refine the proposal by enumerating services.
 - Carlos: Agree on setting up a working group.
   - I would want to be on the one for glibc to enumerate services.
 - David: We need the enumeration of current services in detail.
   - There are two here.
 - Siddhesh: Does it make sense to have an in-principle vote early?
   - Have the GNU Toolchain leadership endorse the exploration?
 - David: The support letter is sufficient to indicate the direction.
 - Siddhesh: Jeff Law mentioned voting.
 - Carlos: Yes, for the final decision to move, the projects must make that decision.
 - Create working group to enumerate project services.
   - Jose: Agree. It would be useful.
   - Nick: Agree.
   - Simon: Agree. Not much experience.
   - David: Agree.
   - Frank: 
     - Note: Frank was muted and did not appear to unmute, or be on IRC.
   - Joseph: Agree. Nothing to add. Important first step.
   - Siddhesh: Agree. Its good. I can help out with services like patchwork.
   - Carlos: Agree. Like Jose said, having this is an important task for any project.
 - Action items:
   - Create the working group via GTI TAC mailing list discussion.
     - Identify members.
     - Initial taks of the WG is to enumerate existing services.
   - Create GTI TAC website with storage for notes and meetings.
     - Done via GTI TAC mailing list discussion.

-- 
Cheers,
Carlos.

Re: GTI TAC Meeting Notes 2022-11-09

[Siddhesh Poyarekar]

On 2022-11-09 12:47, Carlos O'Donell wrote:
>   - Siddhesh: Could we just use some of the LF and OpenSSF stuff?
>   - David: Some of that could be non-FOSS
>   - Siddhesh: Do we have concerns about non-FOSS for the TAC?

Specifically, I wanted to know if reusing their github project 
namespaces was acceptable.

>   - David: Yes.
>   - Siddhesh: Yes, a simple solution would work.
>   - David: Also have.
>     - toolchains.dev
>     - tollchain-infrastructure.org
> - Regarding the GNU Toolchain infrastrucutre at the LF IT proposal
>   - Next steps?
>   - Create a working group.
>   - Detailed assessment of the current technoloyg and services.
>     - Enumerate the features.
>   - Wether the GTI TAC or subgroup, working with the LF IT
>   - Use the more detailed list to do the analysis and sizing
>     of effort and expense for:
>     - Steady state provisioning of the services.
>     - Transitioning the services.
>   - With that plan and budget, the GTI TAC votes on that.
>   - Plan goes out for review.
>   - Jose: Do I have your permission to be a little bit naive here.
>     - The GNU Toolchain projects are GNU projects.
>     - The projects have had a historical process.
>     - How do we make that decision?
>   - Carlos: That would be for the GNU Toolchain projects to decide that.
>   - David: Yes, this needs to go out to those projects to make their decisions.
>   - Jose: That's clear.
>   - Siddhesh: Yes, there is a bit of word soup here. The "Leadership" is the
>     general term here because multiple projects use different nomenclature.

To add some more detail (since this question has come up multiple times 
in previous years), we have:

- gcc: GCC Steering committee as the GNU/FSF representatives
- glibc: FSF Stewards.  GNU maintainers (i.e. on Savannah) don't have 
special powers in this context
- gdb: FSF appointed GDB Maintainers
- binutils: Nick and Alan (what do y'all call yourselves?  The GNU 
maintainer list on savannah looks different :) )

Sid

Re: GTI TAC Meeting Notes 2022-11-09

[Jeff Law]

On 11/9/22 10:47, Carlos O'Donell wrote:
> GTI TAC Meeting Notes 2022-11-09

[ ... ]

THanks.  I'll review these over the next couple days.  I thought I was 
going to be able to make it this morning, but a medical issue got in the 
way (I'm going to be fine).


Jeff

Re: GTI TAC Meeting Notes 2022-11-09

[Siddhesh Poyarekar]

On 2022-11-09 15:49, Jose E. Marchesi wrote:
> I don't know what a "FSF steward" is, exactly.  I have only heard the
> term in the context of GCC and glibc, and always assumed it was a
> peculiar way to refer to the GNU maintainers.

In fact I think it's specifically in the context of glibc[1], I don't 
think other projects use the "FSF Stewards" or "Project Stewards" terms. 
  It was probably in the aftermath of the transition of the community 
around 2011 where the project moved to a consensus based development 
model and AFAICT the then maintainers wanted to broaden who they called 
"maintainers".  gcc is not the only project with a colorful history in 
that regard :)

So yes, FSF Steward does refer to GNU maintainers.

> GNU maintainership is certainly well defined, both in scope and
> extension.
> 
> The GNU maintainers are appointed by the GNU Project, and at the time of
> being appointed they agree to, among several other things, apply the GNU
> policies, be the responsibles for the package GNU-wide, and notify GNU
> if at some point they can't or dont want to maintain the package
> anymore.
> 
> The official GNU maintainers are listed in the records in fencepost (not
> in savannah) and for the four toolchain projects they are, as of today:

<snip>

Yes, these are precisely the people who will be making decisions on 
behalf of and in the interest of their respective projects.

Thanks,
Sid

[1] 
https://sourceware.org/glibc/wiki/MAINTAINERS#Project_stewards_.28GNU_package_maintainers.29