From https://blog.centos.org/2020/01/minutes-for-centos-board-of-directors-2019-1...
Public minutes
On 2019-12-18 the CentOS Board of Directors held the final meeting of the 2019 calendar year.
The meeting was focused primarily on how the Board can lead the project further into being a contributor-centric open source project while continuing to deliver value to our community of users. Of particular interest is growing participation in CentOS Streams in addition to ongoing efforts around CentOS SIGs.
As a centralizing effort, the Board agreed to revisiting the goals document created five years ago, and to undergo an effort to refresh those goals in the light of the project’s evolution. The Board will be inviting various stakeholders into these discussions as we undergo a public revision of the goals at the start of 2020.
In support of these efforts, the Board came to the following decisions, resolutions, and agreements:
1. Image creation, signing, and distribution: 1. AGREED: Board agrees there is a significant technical debt in the content flow. To address this the Board authorizes Community Platform Engineering (CPE) to commit engineering toward addressing this in early CY 2020. 2. ACTION: Jim to work with Fabian/CPE to begin working on a signing and release solution for SIGs, work starting in Jan 2020. 3. ACTION: Prioritize transparency and reporting to foster a better understanding of the build process for CentOS Linux 8, with an emphasis on the update lag/point release challenges
2. Project strategic goals: 1. AGREED: Undergo a revision of the project goals, to include a range of topics from technical to social/cultural. Do this work transparently, reaching out to specific community members and stakeholders such as RHEL Engineering.
3. Consent agenda items: 1. AGREED: Secretary role revitalized -- not formally in the governance yet, role is delegated meeting organization and management duties from the Chair to include calling for meetings, managing the private and public agenda for meetings, and handling the creation and release of private and public minutes. Karsten Wade has volunteered to take this role until approximately June 2020. 2. ACTION: Early in 2020 Karsten & KB to draft governance updates to reflect the Secretary role. AGREED: Board confirms support for planning a shift to sharing auth backends with the Fedora Project.
(Resending with fixed formatting, the Mailman archives will thank me)
From https://blog.centos.org/2020/01/minutes-for-centos-board-of-directors-2019-1...
Public minutes
On 2019-12-18 the CentOS Board of Directors held the final meeting of the 2019 calendar year.
The meeting was focused primarily on how the Board can lead the project further into being a contributor-centric open source project while continuing to deliver value to our community of users. Of particular interest is growing participation in CentOS Stream in addition to ongoing efforts around CentOS SIGs.
As a centralizing effort, the Board agreed to revisiting the goals document created five years ago, and to undergo an effort to refresh those goals in the light of the project’s evolution. The Board will be inviting various stakeholders into these discussions as we undergo a public revision of the goals at the start of 2020.
In support of these efforts, the Board came to the following decisions, resolutions, and agreements:
1. Image creation, signing, and distribution: 1. AGREED: Board agrees there is a significant technical debt in the content flow. To address this the Board authorizes Community Platform Engineering (CPE) to commit engineering toward addressing this in early CY 2020. 2. ACTION: Jim to work with Fabian/CPE to begin working on a signing and release solution for SIGs, work starting in Jan 2020. 3. ACTION: Prioritize transparency and reporting to foster a better understanding of the build process for CentOS Linux 8, with an emphasis on the update lag/point release challenges
2. Project strategic goals: 1. AGREED: Undergo a revision of the project goals, to include a range of topics from technical to social/cultural. Do this work transparently, reaching out to specific community members and stakeholders such as RHEL Engineering.
3. Consent agenda items: 1. AGREED: Secretary role revitalized -- not formally in the governance yet, role is delegated meeting organization and management duties from the Chair to include calling for meetings, managing the private and public agenda for meetings, and handling the creation and release of private and public minutes. Karsten Wade has volunteered to take this role until approximately June 2020. 2. ACTION: Early in 2020 Karsten & KB to draft governance updates to reflect the Secretary role. 2. AGREED: Board confirms support for planning a shift to sharing auth backends with the Fedora Project.
On Fri, Jan 03, 2020 at 03:13:53PM -0500, Karsten Wade wrote:
As a centralizing effort, the Board agreed to revisiting the goals document created five years ago, and to undergo an effort to refresh those goals in the light of the project’s evolution. The Board will be inviting various stakeholders into these discussions as we undergo a public revision of the goals at the start of 2020.
Wow, five years goes fast! I'd like to raise an idea for discussion and thought, and possible further discussion between the Fedora Council and the CentOS board. [I'm posting this in both groups.]
Around the same time the CentOS goals were being created, Fedora was working on plans for "Fedora.next", which included among other things Fedora Server. I won't rehash all that here, but in short: while that succeeded at some of its goals, it never really had the user adoption we'd hoped for. Of course, some of that is simply a matter of lifecycle: while a fast-moving server OS is useful in some very real cases, it's decidedly niche.
When Fedora launched that plan, CentOS wasn't really in the "family", and after, we just kind of existed in parallel, with some very loose collaboration in areas like EPEL.
Of course, things are different now. Therefore, I propose that in this next decade, we make that collaboration stronger. Together, we have a very nice answer to the fundamental problem of unified operating systems. That is, some parts move too fast and other parts move too slowly. Between Fedora and CentOS, we have answers to both! And, with the in-progress dist-git merge, we even have both _in the same place_.
Specifically, I'd like to suggest three things.
First, let's replace Fedora Server as a user-focused artifact with CentOS Stream. There's still a need for a Fedora Server as an upstream, but most users of Fedora as a server are making custom builds (or using the basic Cloud image), not using Fedora Server per se. So, I think we should stop marketing that to users, and steer people with server use cases outside of the fast-moving niche to CentOS Stream. The current story of CentOS and Fedora is pretty confusing to users, and Stream only makes it more so. Let's simplify things!
Second, where there's overlap, let's look at merging Fedora and CentOS SIGs into joint bodies. We have groups like the cloud image SIGs which are basically doing the exact same thing in two different ways. Same thing with containers. We also have huge overlaps in documentation and community user support and all sorts of non-technical project areas. I'm not saying these all need to be smooshed together, but where it makes sense let's work together. This, too, brings simplification to the "what's with CentOS vs. Fedora" story: rather than making contributors pick, we can welcome all with open arms.
And finally, let's really take advantage of a merged dist-git repository, and the capabilities that Modularity gives us. SIGs building things for CentOS should be able to directly reference Fedora branches where faster-moving software is useful — and people building things in Fedora should be able to pull in branches from Stream where a slower-moving version would make sense. And we could even make additional shared branches where necessary, using modularity to make optional streams which could be used in CentOS SIGs, EPEL, or a Fedora OS.
What do you think?
On 1/6/20 4:12 PM, Matthew Miller wrote:
Second, where there's overlap, let's look at merging Fedora and CentOS SIGs into joint bodies. We have groups like the cloud image SIGs which are basically doing the exact same thing in two different ways. Same thing with containers. We also have huge overlaps in documentation and community user support and all sorts of non-technical project areas. I'm not saying these all need to be smooshed together, but where it makes sense let's work together. This, too, brings simplification to the "what's with CentOS vs. Fedora" story: rather than making contributors pick, we can welcome all with open arms.
I know that a number of us will be at FOSDEM in a few weeks. Would it be possible to find some space/time to brainstorm about what exactly this would entail, and see what the path to this looks like?
Friday, we have the Dojo, but perhaps Saturday or Sunday?
On Mon, Jan 6, 2020 at 4:13 PM Matthew Miller mattdm@mattdm.org wrote
And finally, let's really take advantage of a merged dist-git repository, and the capabilities that Modularity gives us. SIGs building things for CentOS should be able to directly reference Fedora branches where faster-moving software is useful — and people building things in Fedora should be able to pull in branches from Stream where a slower-moving version would make sense. And we could even make additional shared branches where necessary, using modularity to make optional streams which could be used in CentOS SIGs, EPEL, or a Fedora OS.
Sounds great.
But I hope we don't have to wait for all that to happen before we get C8 buildroots in CBS for the SIGs to build packages.
--
Kaleb
On Tue, Jan 07, 2020 at 12:39:40PM -0500, Kaleb Keithley wrote:
would make sense. And we could even make additional shared branches where necessary, using modularity to make optional streams which could be used in CentOS SIGs, EPEL, or a Fedora OS.
Sounds great.
But I hope we don't have to wait for all that to happen before we get C8 buildroots in CBS for the SIGs to build packages.
Is it possible for SIGs to build those packages in EPEL directly or Copr (via the EPEL 8 target) in the meantime?
On Tue, Jan 7, 2020 at 1:01 PM Matthew Miller mattdm@mattdm.org wrote:
On Tue, Jan 07, 2020 at 12:39:40PM -0500, Kaleb Keithley wrote:
would make sense. And we could even make additional shared branches where necessary, using modularity to make optional streams which could be used in CentOS SIGs, EPEL, or a Fedora OS.
Sounds great.
But I hope we don't have to wait for all that to happen before we get C8 buildroots in CBS for the SIGs to build packages.
Is it possible for SIGs to build those packages in EPEL directly or Copr (via the EPEL 8 target) in the meantime?
It is possible. I can (and do) build --scratch packages in koji. I can't do real builds in EPEL because there are downstream packages in RHEL.
But whether I build them there or in Copr it's still not the same as having them in the CentOS $sig repos and have them be installable using the $package-repo RPM from Extras. It's about convenience for the end users, one stop shopping, the appearance of legitimacy and the cachet of being a part of CentOS, etc.
Which was the point of putting our packages in the (Storage) SIG in the first place.
Asking us to build them in EPEL or Copr is a step backwards.
--
Kaleb
On Tue, Jan 07, 2020 at 03:12:25PM -0500, Kaleb Keithley wrote:
Asking us to build them in EPEL or Copr is a step backwards.
Copr is intentionally the wild west, so I understand that -- that's just a stop-gap suggestion. But for EPEL: what would it take so having CentOS SIG artifacts in EPEL *wouldn't* feel like a step backwards? I think that should be a goal.
On Tue, Jan 7, 2020 at 8:22 PM Matthew Miller mattdm@mattdm.org wrote:
On Tue, Jan 07, 2020 at 03:12:25PM -0500, Kaleb Keithley wrote:
Asking us to build them in EPEL or Copr is a step backwards.
Copr is intentionally the wild west, so I understand that -- that's just a stop-gap suggestion. But for EPEL: what would it take so having CentOS SIG artifacts in EPEL *wouldn't* feel like a step backwards? I think that should be a goal.
How is that different than just building them in EPEL and being done with it.
Has something changed in the EPEL rules that would now allow us to ship packages that conflict with the packages in base RHEL or a RHEL product like RHGS (GlusterFS) or RHCS (Ceph)?
It also doesn't solve being able to ship multiple versions in separate repos, e.g. gluster-5, gluster-6, and gluster-7. (I want to call those Streams, but I think Streams is used for something different.)
--
Kaleb
On Wed, Jan 08, 2020 at 06:35:13AM -0500, Kaleb Keithley wrote:
How is that different than just building them in EPEL and being done with it.
Has something changed in the EPEL rules that would now allow us to ship packages that conflict with the packages in base RHEL or a RHEL product like RHGS (GlusterFS) or RHCS (Ceph)?
Yes -- this should be possible with modularity. You'd ship the conflicting packages as an alternate stream. No default streams allowed, but people could opt in. And presumably there could exist media where that stream is enabled by default.
It also doesn't solve being able to ship multiple versions in separate repos, e.g. gluster-5, gluster-6, and gluster-7. (I want to call those Streams, but I think Streams is used for something different.)
Streams is right, actually. As opposed to "CentOS Stream", singular.
On Thu, Jan 9, 2020 at 10:55 AM Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jan 08, 2020 at 06:35:13AM -0500, Kaleb Keithley wrote:
How is that different than just building them in EPEL and being done with it.
Has something changed in the EPEL rules that would now allow us to ship packages that conflict with the packages in base RHEL or a RHEL product like RHGS (GlusterFS) or RHCS (Ceph)?
Yes -- this should be possible with modularity. You'd ship the conflicting packages as an alternate stream. No default streams allowed, but people could opt in. And presumably there could exist media where that stream is enabled by default.
It also doesn't solve being able to ship multiple versions in separate repos, e.g. gluster-5, gluster-6, and gluster-7. (I want to call those Streams, but I think Streams is used for something different.)
Streams is right, actually. As opposed to "CentOS Stream", singular.
I'll add a tiny bit of extra clarification here as this vocabulary is new to many people.
* RHEL Application Streams uses modularity to provide users multiple version options to meet their use case needs. For example, RHEL 8.1 provides PostgreSQL 9.6 and 10 (default version). These multiple application streams are made available from a single repository to provide easy access. Think of this as single repo with choices for different app versions, but a single Operating System distribution version.
* CentOS Stream is a distribution development stream of an entire OS that includes multiple repositories. So think of this more as the entire distribution, which just so happens to include a repository called appstreams providing the item above.
So based on what Matthew said, it sounds like changes to EPEL would allow it to provide a different set of "application streams" (enabled by modularity) of options for users to choose from and this repo could be used by both RHEL and CentOS.
I'm not sure if that helps or makes it more confusing, but I tried :-D
Thank you, Terry Bowling Sr. Product Manager - RHEL Automation & Management Red Hat, Inc.
On Thu, Jan 9, 2020 at 10:55 AM Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jan 08, 2020 at 06:35:13AM -0500, Kaleb Keithley wrote:
How is that different than just building them in EPEL and being done with it.
Has something changed in the EPEL rules that would now allow us to ship packages that conflict with the packages in base RHEL or a RHEL product like RHGS (GlusterFS) or RHCS (Ceph)?
Yes -- this should be possible with modularity. You'd ship the conflicting packages as an alternate stream. No default streams allowed, but people could opt in. And presumably there could exist media where that stream is enabled by default.
It almost certainly is possible with modularity, but that's a big chunk to bite off.
More than I have time to tackle at the moment I'm afraid. AFAIK Niels (ndevos, my "partner" for Gluster, and to a lesser extent NFS-Ganesha) has no desire, or time, to do anything with modularization.
--
Kaleb
On Thu, Jan 9, 2020 at 10:55 AM Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jan 08, 2020 at 06:35:13AM -0500, Kaleb Keithley wrote:
How is that different than just building them in EPEL and being done with it.
Has something changed in the EPEL rules that would now allow us to ship packages that conflict with the packages in base RHEL or a RHEL product like RHGS (GlusterFS) or RHCS (Ceph)?
Yes -- this should be possible with modularity. You'd ship the conflicting packages as an alternate stream. No default streams allowed, but people could opt in. And presumably there could exist media where that stream is enabled by default.
Since modularity has been pretty firmly proven not to work, both for RHEL 8 and in Fedora, why would you even consider relying on it. It's already preven a destabilizing influence in RHEL and CentOS 8 and pretty much discarded for Fedora 32. The current chafing example in RHEL 8 and CentPS 8 is Perl dependencies, but they keep happening. I've not yet seen any hint that they will be any significant part of Fedora 32.
On Thu, Jan 9, 2020 at 8:54 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Jan 9, 2020 at 10:55 AM Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jan 08, 2020 at 06:35:13AM -0500, Kaleb Keithley wrote:
How is that different than just building them in EPEL and being done with it.
Has something changed in the EPEL rules that would now allow us to ship packages that conflict with the packages in base RHEL or a RHEL product like RHGS (GlusterFS) or RHCS (Ceph)?
Yes -- this should be possible with modularity. You'd ship the conflicting packages as an alternate stream. No default streams allowed, but people could opt in. And presumably there could exist media where that stream is enabled by default.
Since modularity has been pretty firmly proven not to work, both for RHEL 8 and in Fedora, why would you even consider relying on it. It's already preven a destabilizing influence in RHEL and CentOS 8 and pretty much discarded for Fedora 32. The current chafing example in RHEL 8 and CentPS 8 is Perl dependencies, but they keep happening. I've not yet seen any hint that they will be any significant part of Fedora 32.
Modularity as a concept has not been "firmly proven not to work". There *are* issues in the current implementation, and I *do* have concerns about the state of affairs as it stands, but it's not over yet! It mostly works fine in RHEL/CentOS 8, even if it is a pain in the neck to build stuff on top of. There's no indication that Modularity is going away for Fedora 32. Indeed, I'm pretty sure there will be significant work going on in the background to make it better.
On 1/9/20 7:54 PM, Nico Kadel-Garcia wrote:
On Thu, Jan 9, 2020 at 10:55 AM Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jan 08, 2020 at 06:35:13AM -0500, Kaleb Keithley wrote:
How is that different than just building them in EPEL and being done with it.
Has something changed in the EPEL rules that would now allow us to ship packages that conflict with the packages in base RHEL or a RHEL product like RHGS (GlusterFS) or RHCS (Ceph)?
Yes -- this should be possible with modularity. You'd ship the conflicting packages as an alternate stream. No default streams allowed, but people could opt in. And presumably there could exist media where that stream is enabled by default.
Since modularity has been pretty firmly proven not to work, both for RHEL 8 and in Fedora, why would you even consider relying on it. It's already preven a destabilizing influence in RHEL and CentOS 8 and pretty much discarded for Fedora 32. The current chafing example in RHEL 8 and CentPS 8 is Perl dependencies, but they keep happening. I've not yet seen any hint that they will be any significant part of Fedora 32.
Well .. Why would CentOS 8 rely on it (modularity) .. because it is in RHEL-8 source code. As to whether or not it is good or the best way to accomplish it's goals .. that is not relevant to it being in CentOS Linux 8.
On 06/01/2020 21:12, Matthew Miller wrote:
And finally, let's really take advantage of a merged dist-git repository, and the capabilities that Modularity gives us. SIGs building things for CentOS should be able to directly reference Fedora branches where faster-moving software is useful — and people building things in Fedora should be able to pull in branches from Stream where a slower-moving version would make sense. And we could even make additional shared branches where necessary, using modularity to make optional streams which could be used in CentOS SIGs, EPEL, or a Fedora OS.
If there's going to be more cross-pollination and shared usage of the two dist-gits, can I ask for two things:
1) Standardise on one dist-git layout (I'd suggest eliminating CentOS', as there's presumably a lot more of Fedora's git history and tooling that would need to be rewritten, not to mention all of the Fedora Koji task SCM URLs would be wrong; yes, CentOS' Koji would be wrong, but again there's a lot less stuff in that that would need fixing up).
2) Separate the upstream RHEL git sources and CentOS' changes, such that there are clean branches or repos containing only the RHEL source import commits. Third parties looking for the RHEL sources should not need to filter out CentOS' debranding / local patches.
-
Howard Johnson -
Johnny Hughes -
Kaleb Keithley -
Karsten Wade -
Matthew Miller -
Neal Gompa -
Nico Kadel-Garcia -
Rich Bowen -
Terry Bowling