[riaankleinhans]

Aligns .project/maintainers.yaml with fluent/fluentd/MAINTAINERS.md:

• Adds fujimots (Fujimoto Seiji) — listed as an active maintainer in fluentd MAINTAINERS.md.
• Removes patrick-stephens — not listed in fluentd MAINTAINERS.md. If Patrick is an active fluentd maintainer whose entry should be added to MAINTAINERS.md, please let me know and I'll adjust this PR accordingly.

Part of CNCF's rollout of .project repos across sandbox/incubating/graduating projects — tracked in cncf/automation#566.

[tagomoris]

LGTM

[ashie]

I think we need to clarify what .project/maintainers.yaml is supposed to represent before removing @patrick-stephens.

The proposed change makes sense if fluent/fluentd/MAINTAINERS.md is the sole source of truth for this file. However, I am not sure that is still the correct model after the recent restructuring of the Fluent project at the CNCF level.

For some historical context:

1. Originally, Fluentd was the CNCF Graduated Project, and Fluent Bit was positioned as a sub-project under the Fluentd umbrella.

2. In April 2024, @edsiper proposed changing the hierarchy so that Fluent Bit would become the primary project:

   Revising Project Hierarchy within the Fluent Organization fluentd#4471

   That proposal did not gain sufficient community support. One of the alternatives discussed was to avoid simply reversing the parent/sub-project relationship and instead place Fluentd and Fluent Bit in parallel.

3. Following discussion with the CNCF TOC, @edsiper opened a different proposal in November 2024:

   [CNCF] Proposal to Restructure Fluentd and Fluent Bit Under the Fluent Organization fluentd#4702

   This proposal explicitly says:

   "I have asked CNCF TOC for guidance and the restructure proposal idea has been provided by them."

   and proposes:

   "Restructure Fluentd and Fluent Bit as part of the broader 'Fluent' organization."

   "Both projects will exist independently under the Fluent organization, governed by the higher-level Fluent governance structure."

   It also specifically notes:

   "this only affects the structure at a CNCF level"

   My understanding was therefore that the intended CNCF-level structure became roughly:

   Fluent (CNCF Graduated project / organization)
   ├── Fluentd
   └── Fluent Bit
   

   with Fluentd and Fluent Bit being peers, rather than:

   Fluentd (CNCF Graduated project)
   └── Fluent Bit (sub-project)
   

4. At KubeCon NA 2025, this restructuring was presented as completed. A slide titled "Organization Update — Renaming Fluentd → Fluent Organization" said:

   "The Fluentd organization has officially been renamed to 'Fluent'"

   and:

   "Now both Fluent Bit and Fluentd are first-class sibling projects under the new Fluent organization."

   A photo of that slide from the session was posted here:

   https://x.com/cosmo__/status/1988650408659841468

   Fluent Bit itself also now identifies itself as a "CNCF graduated project", and its runtime banner says that it is a CNCF graduated project under the Fluent organization: https://fluentbit.io/

Given that history, I don't think we should automatically use only fluent/fluentd/MAINTAINERS.md as the source of truth for an organization-level .project/maintainers.yaml.

In particular, we already have separate maintainer lists for the two sibling projects:

• fluent/fluentd/MAINTAINERS.md
• fluent/fluent-bit/MAINTAINERS.md

If Fluentd and Fluent Bit are now first-class sibling projects under the Fluent organization, it seems more natural that an organization-level maintainer roster should take both of these lists into account, rather than treating the Fluentd list as the maintainer list for the entire Fluent organization.

This is directly relevant to @patrick-stephens. He is not listed in fluent/fluentd/MAINTAINERS.md, but he is listed in fluent/fluent-bit/MAINTAINERS.md and remains involved in maintaining Fluent Bit. So removing him from .project/maintainers.yaml simply because he is absent from the Fluentd maintainer list does not seem consistent with the sibling-project structure described above.

If .project/maintainers.yaml represents the CNCF-level Fluent project/organization rather than specifically the Fluentd repository, my expectation would therefore be that it should be derived from the appropriate combination (probably the union) of:

• fluent/fluentd/MAINTAINERS.md
• fluent/fluent-bit/MAINTAINERS.md

rather than from fluent/fluentd/MAINTAINERS.md alone.

There is one important thing I cannot confirm, though.

While I can find the community proposal, the discussion with CNCF TOC mentioned by Eduardo, and the KubeCon presentation saying that the restructuring was officially completed, I have not been able to find a CNCF/TOC-side announcement, decision record, or governance document that clearly defines the resulting structure and what the canonical maintainer list for the "Fluent" CNCF project should be.

In other words, there seems to be good evidence that the restructuring happened, but I cannot independently confirm exactly how CNCF models this internally or what .project/maintainers.yaml is expected to represent after the restructuring.

@edsiper, since you coordinated this restructuring with CNCF, could you clarify the current status from the CNCF side?

In particular:

• Was the restructuring described in [CNCF] Proposal to Restructure Fluentd and Fluent Bit Under the Fluent Organization fluentd#4702 formally completed on the CNCF side as presented at KubeCon NA 2025?
• Does CNCF now consider Fluentd and Fluent Bit first-class sibling projects under a single Graduated "Fluent" project/organization?
• What exactly is .project/maintainers.yaml expected to represent in that structure?
• If it represents the Fluent project/organization, should it contain the appropriate combination of the maintainers from both fluent/fluentd/MAINTAINERS.md and fluent/fluent-bit/MAINTAINERS.md?
• Is there a CNCF-side document, PR, issue, or other source of truth describing this structure that we can reference here?

If the understanding above is correct, my suggestion for this PR would be:

1. I think @patrick-stephens should remain in .project/maintainers.yaml, since he is listed in fluent/fluent-bit/MAINTAINERS.md. If Fluentd and Fluent Bit are now first-class sibling projects under the Fluent organization, being absent from fluent/fluentd/MAINTAINERS.md should not by itself be a reason to remove a Fluent Bit maintainer from the organization-level maintainer list.
2. Build .project/maintainers.yaml from the appropriate combination of both fluent/fluentd/MAINTAINERS.md and fluent/fluent-bit/MAINTAINERS.md, according to CNCF's definition of a project/organization maintainer.
3. Ideally document these sources of truth somewhere under .project, so that future synchronization does not accidentally treat the Fluentd maintainer list as the maintainer list for the entire Fluent organization.

Of course, if CNCF still formally treats Fluentd as the project whose maintainer roster alone must populate .project/maintainers.yaml, then the current approach may be correct. I think we should confirm that point before removing Fluent Bit maintainers from this file.

[ashie]

Let me summarize my point:

• If Fluentd and Fluent Bit are officially sibling projects, .project/maintainers.yaml should include maintainers from both.
• The KubeCon NA 2025 presentation suggests that this restructuring has already been officially completed.
• I couldn't find definitive CNCF-side documentation, so I'd like @edsiper to confirm the current status.

[patrick-stephens]

Thanks @ashie for that very comprehensive summary and keeping me in the list. As you say I've not been involved in fluentd but do help maintain Fluent Bit.

[ahmadqasembader]

Hi @ashie

I'm awaiting @edsiper confirmation on the project status, as you mentioned above.

However, if Fluent and Fluent Bit are 2 different projects (regardless of whether the same Org or Committee maintains them), .project can accommodate this use case, which basically means: one GH Org -> 2 CNCF Projects -> one .project repo for both projects.

Let me know your decision, and I can guide you accordingly.

[edsiper]

Thanks @ashie and @ahmadqasembader.

Yes, the intended and community-approved structure is:

Fluent
├── Fluentd
└── Fluent Bit

Fluentd and Fluent Bit should be treated as first-class sibling projects under the Fluent umbrella, rather than Fluent Bit being a sub-project of Fluentd (or vice versa).

This was the outcome of the restructuring proposal discussed in fluent/fluentd#4702, after the earlier proposal to change the primary/sub-project relationship did not move forward.

One clarification on the current status: while the community side was agreed and we presented the new structure at KubeCon NA 2025, I am currently reconfirming with the CNCF Projects team that every administrative step on the CNCF side was fully completed. We had some organizational/email changes during this period and some follow-up items may have been left incomplete. I have just restarted that thread with projects@cncf.io.

For purposes of this PR, though, I don't think we should go back to treating fluentd/MAINTAINERS.md as the maintainer list for the entire Fluent organization.

Given what @ahmadqasembader confirmed that .project supports one GitHub organization with two CNCF projects..I think that is the model we should use here.

So my preference would be:

• represent Fluentd and Fluent Bit separately inside .project;
• use each project's own maintainer list as its source of truth;
• keep @patrick-stephens as a Fluent Bit maintainer;
• add @fujimots as a Fluentd maintainer , HOWEVER that handle @fujimots is no longer active ?

avoid creating a single combined maintainer roster unless .project specifically requires an organization-level group in addition to the two project groups.

@ahmadqasembader, if you can point us to the recommended .project structure for the "one GH org → two CNCF projects" case, I think we can update this PR accordingly while I close the remaining CNCF-side administrative follow-up.

[ahmadqasembader]

Thanks, @edsiper for the confirmation.

For the time being, and for the purpose of this PR, can we please treat Fluent Bit maintainers as Fluent maintainers until we roll out the new structure to this repo?

Since the one Org -> 2 Projects structure is a new use case we discovered for only a few Graduated Projects (such as SPIFFE) and now Fluent, we still haven't fully enabled this feature (will be available probably next week). I will ping you again when it's ready and make the necessary adjustments myself to this repo and request your review.

The changes will look like this:

.project repo contains 2 folders -> FluentD (project 1) and Fluent Bit (project 2), and the root folder will contain the shared governance files, and project-specific files will be under each project folder, such as the maintainer list.

cc @riaankleinhans

[edsiper]

yeah sure, that sounds good to me

[ashie]

@ahmadqasembader @edsiper That's good, thanks!

• add @fujimots as a Fluentd maintainer , HOWEVER that handle @fujimots is no longer active ?

Yes, he is no longer active.
However it should be a separated discussion: e.g.) fluent/fluentd#4150
In this context, it would be better to focus only on the point of which list the .project/maintainers.md file automatically maps to.

[edsiper]

@ahmadqasembader @edsiper That's good, thanks!

• add @fujimots as a Fluentd maintainer , HOWEVER that handle @fujimots is no longer active ?

Yes, he is no longer active. However it should be a separated discussion: e.g.) fluent/fluentd#4150 In this context, it would be better to focus only on the point of which list the .project/maintainers.md file automatically maps to.

yeah I agree. But note that my comment is about that https://github.com/fujimots is a no longer active account on github:

Unless we have his proper github handle we should not add the old one as this PR suggest.

[ashie]

yeah I agree. But note that my comment is about that https://github.com/fujimots is a no longer active account on github:

Oh, I hadn't noticed that. Thank you for pointing it out.
(When I checked his account information probably about a month ago, it was still active.)

Unless we have his proper github handle we should not add the old one as this PR suggest.

Yeah, I agree with you.

[ashie]

yeah I agree. But note that my comment is about that https://github.com/fujimots is a no longer active account on github:

Oh, I hadn't noticed that. Thank you for pointing it out. (When I checked his account information probably about a month ago, it was still active.)

Unless we have his proper github handle we should not add the old one as this PR suggest.

Yeah, I agree with you.

Oops, I've noticed that it's typo in fluent/fluentd/MAINTAINERS.md.
His correct account is https://github.com/fujimotos, it's still active.

- fujimots
+ fujimotos

In addition, his correct account name exists in fluent/fluent-bit/MAINTAINERS.md.

[edsiper]

@ashie thanks for the clarification :)

@riaankleinhans so I think the next step is just to modify the PR to point out the right handle for @fujimotos

[ashie]

@riaankleinhans so I think the next step is just to modify the PR to point out the right handle for @fujimotos

We've fixed fluent/fluentd/MAINTAINERS.md.

[riaankleinhans]

Thank you @ashie for reviewing.
Updated GH Handle pushed. Please review and merge when you are ready.

[patrick-stephens]

So this has removed me but not added the separate Fluent Bit project, is that intended?
It sounds like we just updated the incorrect handle but I think there was an intent to create the second project or is that a separate PR?