#292 Council statements on gitforge next steps
Opened 2 months ago by mattdm. Modified a month ago

This is a continuation of our meeting discussion earlier this week. I think we as the council should provide some further guidance to CPE based on community feedback, and also make sure our position and vision as the Council is clear to the community. I’d like us to agree on three basic points.

  1. We hear the community on the importance of free and open source software in our infrastructure, and as part of the community ourselves agree with that importance. The policy we adopted in 2018 allows us to be pragmatic and flexible, rather than dogmatic. In this case, we believe that an open source solution for our dist-git needs can be viable, and reflect community consensus that in this case it is a hard requirement.

  2. Fedora’s dist-git is provided to us by CPE, and the future of what they provide to the project is ultimately their decision. CPE team members are part of the Fedora community, and we know they share our passion for our project’s success. As the Council, we trust CPE to balance our requirements with the needs of CentOS and RHEL and come up with something that works for everyone and will be good for Fedora long-term.

  3. Fedora is a part of a family of operating system projects, and it is to our huge advantage to share tooling and processes with RHEL and CentOS. Closer continuous collaboration with RHEL will free us from the “boom/bust” cycle of Red Hat attention around RHEL releases, and help Red Hat be a better sponsor. Closer collaboration with CentOS helps build our user and contributor community and increase the impact of everything we do, and will help us solve problems we can’t with our fast-moving software stream alone.

Does everyone basically agree with these? Let’s make an official statement.


I basically agree. I would also like to mention something that there should be an easy path for contributors to submit patches for core services to ensure that they can address their needs if the service lacks something.

Well, I think it's quite likely there will always be some resistance no matter what piece of the infrastructure you're trying to replace with something non-free, regardless of how expensive (in terms of people's time, resources and money) the free option is.

Terms like "viable" or "core services" mean different things to different people.

I agree with the second and the third points, not the first one. I'll abstain.

A question of dist-git is an Engineering question (with strong FOSS and community aspects). I see Council as a governance body for the Fedora project, but things that impact the Fedora distro on technical level should IMHO be reviewed at FESCo.

CPE management decided to go trough Council, and sadly nobody from the Council looped FESCo into the decision process here (neither the Fedora Council Engineering Rep nor the Fedora Project Leader nor Fedora Program Manager nor anybody else). I feel like the communication between Council and FESCo is now basically at zero (except Ben handling the regular Change process and similar things that are wired to go trough FESCo).

Nonetheless, the choice of the dist-git backend has a huge impact on packaging and other aspects of how we put Fedora together. Can we please add point 4. to this that says that FESCo should be in center of this decision process?

As a side note: I am specifically not saying "git forge" but "dist-git". My concerns are not so much about pagure.io but about src.fedoraproject.org.

I'd like to point out every other major infrastructure change has gone through the change process, debated publicly, and approved by FESCo before implementing:

I think this statement elevates the role of CPE above and outside of normal Fedora governance, and the Council making a statement like that would be a mistake:

Fedora’s dist-git is provided to us by CPE, and the future of what they provide to the project is ultimately their decision.

Let me try this with a different team:

Fedora's systemd package is provided to us by systemd-maint team, and the future of what they provide to the project it ultimately their decision.

It is true that teams and contributors in Fedora have a large leeway in the domains they "own", but there are various rules and policies and big changes undergo public discussion and approval. Members have to conform, and in the extreme cases, ownership is taken away.

I'm not saying here that CPE is doing something wrong. I'm only saying that the Council shouldn't say that community governance does not apply to services provided by CPE.

Thanks to the Council for taking action on this, and especially thanks for "In this case, we believe that an open source solution for our dist-git needs can be viable, and reflect community consensus that in this case it is a hard requirement", I am glad to see that.

To a degree I share the concerns of some other commenters about the broader relationship between CPE and Fedora here, but I also recognize this is a somewhat complex situation, given that CPE is not exactly just a "Fedora team" in the way "Fedora infra" and "Fedora releng" were. I don't think there's exactly an easy answer as to how the relationships between CPE, Red Hat management, and the governance structures of Fedora and CentOS should work, but it does seem like there may still be issues to resolve there.

For the record, I also agree with @zbyszek and believe the point 2 should be dropped or reworded.
It sets a bad precedent and goes very much against what CPE is (or what its team members think it is).

CPE is part of the Fedora community and as such it needs to follow the rules that the community set for itself, one of which being to follow the directives provided its leading committees, be that the Council or FESCo.

+1 on what @pingou and @zbyszek said, we want to flow through the right channels and have the right approvals / authorization for any project that has an impact. Our engagement on this Gitforge conversation was through a channel we in CPE believed to be the right one. The commentary is clearly stating that was not the right channel for this particular discussion and I respect that it was not the case but it was not an intentional bypassing of established processed. We would certainly welcome clarity in who, where, when and how to engage going forward as we want this relationship to be collaborative.

I think we could potentially reword point 2 to help resolve the disconnect:

Fedora’s dist-git is currently provided to us by CPE. The future of what they provide to the project is a decision they will make based on a transparent set of requirements agreed on by FESCo, Council and interested community members. CPE team members are part of the Fedora community, and we know they share our passion for our project’s success. As the Council, we trust CPE to balance our requirements with the needs of CentOS and RHEL and come up with something that works for everyone and will be good for Fedora long-term.

Let me try this with a different team:

Fedora's systemd package is provided to us by systemd-maint team, and the future of what they provide to the project it ultimately their decision.

Yes, I think this is fundamentally true. And we've seen it in action over the years. We can provide some broad guidance and adjustments for Fedora needs, but ultimately we follow the upstream.

For the record, I also agree with @zbyszek and believe the point 2 should be dropped or reworded.
It sets a bad precedent and goes very much against what CPE is (or what its team members think it is).
CPE is part of the Fedora community and as such it needs to follow the rules that the community set for itself, one of which being to follow the directives provided its leading committees, be that the Council or FESCo.

I don't disagree with this, and it doesn't sound like anyone else does either. @pingou, does Marie's rewording work for you? Or do you have an alternate suggestion?

I should add that I don't mean for point 2 (as originally worded or updated) to contradict point 1, so anything to make it clear that that's not the intention is probably helpful. :)

Fedora’s dist-git is currently provided to us by CPE. The future of what they provide to the project is a decision they will make based on a transparent set of requirements agreed on by FESCo, Council and interested community members. CPE team members are part of the Fedora community, and we know they share our passion for our project’s success. As the Council, we trust CPE to balance our requirements with the needs of CentOS and RHEL and come up with something that works for everyone and will be good for Fedora long-term.

+1 to the edit

@pingou, does Marie's rewording work for you? Or do you have an alternate suggestion?

It reads much better than the previous version imo.

Fedora’s dist-git is currently provided to us by CPE. The future of what they provide to the project is a decision they will make based on a transparent set of requirements agreed on by FESCo, Council and interested community members. CPE team members are part of the Fedora community, and we know they share our passion for our project’s success. As the Council, we trust CPE to balance our requirements with the needs of CentOS and RHEL and come up with something that works for everyone and will be good for Fedora long-term.

I like @riecatnor 's edit of point 2.

With this, I'm +1 to the statement.

Is this:

https://communityblog.fedoraproject.org/fedora-council-and-the-git-forge/

intended to be the same statement as the "three basic points" above? Or is there some other venue where the three basic points are to be announced as a council resolution?

The latter. The blog post is more immediate and less official.

I agree with 1, 3.

I somewhat agree with point 2 after riecatnor's edit...I would add the following:

I think decisions like these should be done publicly and people from the community should be able to contribute to the decision making process. I.e. the process should be transparent and open. CPE should be conductor of the process but the decision-making itself should be spread among community members, FESCo, release engineers from different teams, etc.

That way also a development plan (at least in sketch) can be made while making the decision.

Additionally, I think a change like this should eventually go through Fedora change process.

Login to comment on this ticket.

Metadata