Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On Thu, Dec 10, 2020 at 1:01 AM Gionatan Danti wrote: > Il 2020-12-10 04:55 Brendan Conoboy ha scritto: > > On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen wrote: > > > >> On 12/9/20 12:10 PM, Brendan Conoboy wrote: > >> > While I'm not sure how we'll get there, it seems like the > >> > mutually satisfying end result would be one where third party binary > >> > drivers work with CentOS Stream kernels. Let's see what we can do. > >> > > >> So, I want to address this part a bit. In MANY cases, it's not a > >> third-party driver that ELrepo packages; it's an in-kernel driver that > >> Red Hat has decided to disable. Such as the megaraid_sas driver I > >> need > >> for my servers. > >> > > > > Ah yes, that's a great call-out. I'm not sure what the plan is there > > (or > > if there is one), but to me it seems like the sort of thing a SIG would > > build. > > Brendan, can you clarify the following points? > I'll take a stab at it, though I'll note Josh Boyer has already provided a few answers to similar questions... > - are you going to keep stable ABI between Stream kernel releases, or > should we expect each kernel to break 3rd party drivers/modules? > All our kernel changes are implemented against the kernel ABI- there is no point in time during release development when we have interim changes in the kernel that ignore the symbols in the whitelist. So basically if your experience of going from one minor release to another has been smooth, the incremental kernels between those two releases would also tend to run smooth, assuming whatever motions happen with the 3rd party drivers/modules behind the scenes continue to happen (for example, rebuilding from source). > - what/how many synchronization points are going to be with RHEL > releases? > I'm not sure I'm interpreting your question correctly, could you restate? I don't want to hit you with detailed process information only to find out I'm answering the wrong question! > - what about security updates? Will they be released *before* the > corresponding RHEL secure patch, or should we expect the (slow) current > update cadency? > RHEL development prioritizes CVE resolution in support streams, followed by current release update streams. > - is an upgrade path from Stream-8 to Stream-9 planned, or the usual > "total server rebuild" will be necessary? > Upgrades are important. We continue to invest in the major release upgrade tooling introduced with the launch of RHEL 8. Full disclosure: the main CentOS point was to be 100% compatible, down > to the specific kernel used, with RHEL. To get that, we lived with: a) > comparatively few packages, b) not-working yum security-only updates and > c) very restrictive selinux policies. > > I am heavily invested in CentOS/RHEL ecosystem and I opened many bug > reports/enhancement requests in the past years, so I would really like > to continue using CentOS. However, using Stream seems to removing the > key selling point (ie: total RHEL compatibility) without clear benefit. > Thanks for the bug reports :-) I hear you on RHEL compatibility. With my OS developer hat on I think CentOS Stream will be more RHEL compatible, but if I put on my old dusty ops hat I can understand why it might not look that way right now. -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On Thu, Dec 10, 2020 at 12:54 AM Phil Perry wrote: > On 10/12/2020 03:55, Brendan Conoboy wrote: > > On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen wrote: > > > >> On 12/9/20 12:10 PM, Brendan Conoboy wrote: > >>> While I'm not sure how we'll get there, it seems like the > >>> mutually satisfying end result would be one where third party binary > >>> drivers work with CentOS Stream kernels. Let's see what we can do. > >>> > >> So, I want to address this part a bit. In MANY cases, it's not a > >> third-party driver that ELrepo packages; it's an in-kernel driver that > >> Red Hat has decided to disable. Such as the megaraid_sas driver I need > >> for my servers. > > > > Ah yes, that's a great call-out. I'm not sure what the plan is there (or > > if there is one), but to me it seems like the sort of thing a SIG would > > build. > > > > Well, yes, about 10 years too late for those discussions I'm afraid ;-) > Yes, but the calculus has changed a bit from 10 years ago, too, no? > And besides, why on earth would Red Hat remove support for older > hardware that you (understandably) no longer want to commit resources to > maintaining, only to turn round and commit resources to maintaining them > in a SIG? That's why you guys reached out to us (elrepo) in the first > place. Note we've moved from me discussing facts about how RHEL works to my unauthoritative opinions on matters ;-) My point is really only this: if past decisions no longer make the most sense in the context of new events, we need to redesign. To the extent we can make things better we should make them better. For this topic it's probably too early to tell if or how things should change in light of the upcoming changes, but it's clear that handling it will make CentOS Stream adoption an option for more people who use CentOS today. -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen wrote: > On 12/9/20 12:10 PM, Brendan Conoboy wrote: > > While I'm not sure how we'll get there, it seems like the > > mutually satisfying end result would be one where third party binary > > drivers work with CentOS Stream kernels. Let's see what we can do. > > > So, I want to address this part a bit. In MANY cases, it's not a > third-party driver that ELrepo packages; it's an in-kernel driver that > Red Hat has decided to disable. Such as the megaraid_sas driver I need > for my servers. > Ah yes, that's a great call-out. I'm not sure what the plan is there (or if there is one), but to me it seems like the sort of thing a SIG would build. -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
On Wed, Dec 9, 2020 at 11:03 AM Christopher Wensink < cwens...@five-star-plastics.com> wrote: > Understanding the flow of packages, is it a fair comparison to say that > moving forward: > Fedora packages could be considered alpha/beta releases of apps > Centos/Stream could be considered beta / Pre-release / Release > candidates of packages / partially stable > RHEL official releases would be considered final release / stable > > Where as before (done 12/2021) > Fedora Packages would be beta / pre-release > then RHEL and CentOS were final release / stable - one with commercial > support and the other with community only support. > > Is that accurate? > Eh, that's something of a mixture of metaphors and facts. Let me make a few approximate details plain. For RHEL 8 the base inheritance went like this: F27 -> RHEL 8 Alpha (internal) F28 -> RHEL 8 Beta (public) 8 Beta -> RHEL 8.0 8.0 -> RHEL 8.1 There were significant differences in kernel and of many cherry picked patches and rebases from upstream, but that was the baseline. For RHEL 9 it should look more like this (this is an approximation): Rawhide (pre-F34) -> ELN -> RHEL 9 Alpha (internal) F34 -> CentOS Stream 9 -> RHEL 9 Beta CentOS Stream 9 -> RHEL 9.0 CentOS Stream 9 -> RHEL 9.1 Similar to 8 there will be some cherry picked patches, rebases from upstream, etc, before things are 100% CentOS Stream, but the above is the approximate expected flow that shows how Fedora and CentOS Stream interact with a new major release, and the position of CentOS Stream as it relates to RHEL. On 12/9/2020 12:54 PM, Matthew Miller wrote: > > On Wed, Dec 09, 2020 at 09:40:22AM +, J Martin Rushton via CentOS > wrote: > >> And exactly the same applies to senior (or retired) admins on their > >> home computers. My main home machine runs about a dozen testbed > >> VMs, DHCP/DNS for the home network, Amanda, NFS and Samba for other > >> machines, ownCloud, Apache, Zotero and DokuWiki for the family. I > >> want a stable server under that lot, not a beta release. > > CentOS Stream will not be a "beta release". That's not how RHEL minor > > release development works. I personally think that it's going to be > stellar > > for your exact use case. > > > > -- > Christopher Wensink > IS Administrator > Five Star Plastics, Inc > 1339 Continental Drive > Eau Claire, WI 54701 > Office: 715-831-1682 > Mobile: 715-563-3112 > Fax: 715-831-6075 > cwens...@five-star-plastics.com > www.five-star-plastics.com > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On Wed, Dec 9, 2020 at 7:21 AM Phil Perry wrote: > On 09/12/2020 03:26, Brendan Conoboy wrote: > > On Tue, Dec 8, 2020 at 4:19 PM Pete Biggs wrote: > > > >> On Tue, 2020-12-08 at 17:54 -0500, Matthew Miller wrote: > >>> On Tue, Dec 08, 2020 at 03:15:17PM +, Pete Biggs wrote: > >> > >>>> "CentOS will become the developer playground" > >>> > >>> This one is categorically not the case. Even Fedora isn't a developer > >>> playground. Everything landing in CentOS Stream is actually *planned* > >> (with > >>> emphasis intentional) to go in a future RHEL release. > >> > >> It's all the talk of SIGs and developing and testing and that Stream > >> will be the centerpiece of that. That's what I meant. > >> > > > > I don't know if I'd call SIGs a playground, but they're certainly an > > important venue for communities to explore variations. > > > > > >>> Previously, all the development around RHEL releases was done in > secret, > >> in > >>> the Red Hat black box. Now it's out of the box and can be watched. > There > >> may > >>> be some launch pains, but I expect the average quality of an update > >> hitting > >>> CentOS Stream to be very high. > >> > >> I don't get that from the documents released today. If Stream is *not* > >> a test-bed, then surely the code that appears in Stream must be fully > >> formed in secret behind the scenes first. Yes, it will appear piecemeal > >> rather than in one big chunk, but it has been categorically denied that > >> Stream is not a RHEL 8.n+1 beta and is more a RHEL 8.n+1 RC/rolling > >> release. > >> > > > > I think maybe some of the nervousness about CentOS Stream comes from RHEL > > seeming opacity on its development model. As one of the architects of > our > > development process I'd be happy to field questions. I'll start by > making > > a two points in case they're in any way unclear: > > > > 1. Everything that goes into RHEL lands upstream first, then the patches > > are backported into the RHEL releases. > > 2. Most of the work we do or plan on doing is in bugzilla.redhat.com. > If > > you go into the RHEL8 product queue today and file a bug you'll see > "CentOS > > Stream" as a "Version" where an issue is encountered. > > > > I think what a lot of people are concerned about is the rolling-release > >> aspect of this. There will be no definitive versioning of CentOS in the > >> future - all you will be able to say is "fully updated" and it won't be > >> possible to slot a CentOS system in to exactly match a RHEL version. > >> Will third party RPMs built against RHEL 8.x be installable on a CentOS > >> 8 Stream system? The answer is surely "it depends", but there are a lot > >> of hardware vendors that target drivers to RHEL releases, which may > >> well make CentOS non-viable for hardware that doesn't have drivers > >> built in to the kernel. > >> > > > > Generally if they follow the ABI guidelines I would expect it to work. > > Those are here: > https://access.redhat.com/articles/rhel8-abi-compatibility > > > > For loadable kernel modules there's a kernel ABI. > > > > > > Hi Brendan, > > This point is *critical*, so I apologise in advance for the lengthy > post, *you* are breaking the kernel ABI between RHEL8 and Stream. > > One of the main unique selling points of RHEL is the stability of it's > kernel ABI. No other distro provides this. The very nature of rolling > kernel updates in Stream breaks the kernel ABI and breaks compatibility > between RHEL8 and Stream. What works on RHEL8 may not work on Stream. At > the kernel level, the two products diverge in fundamental compatibility > and are not compatible, are no longer the same. > > How bad is this divergence / breakage? Well, we know the kernel ABI will > change from time to time, almost exclusively at new point releases due > to the massive backporting work that goes into the RHEL kernel. And this > is fine, we know it's coming, we know when it's coming, and we can plan > for it's impact. It's a price well worth paying. > > To put this in context, at elrepo I currently help maintain around 50 > 3rd party kernel driver packages for RHEL8. When RH released RHEL8.3, > every single package in our repository broke due to changes in the > kernel ABI in the 6 month period between RHEL8.2 and RHEL8.3. It's not > ideal, but we accept it as a price
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On Wed, Dec 9, 2020 at 1:41 AM Pete Biggs wrote: > > I think what a lot of people are concerned about is the rolling-release > > > aspect of this. There will be no definitive versioning of CentOS in the > > > future - all you will be able to say is "fully updated" and it won't be > > > possible to slot a CentOS system in to exactly match a RHEL version. > > > Will third party RPMs built against RHEL 8.x be installable on a CentOS > > > 8 Stream system? The answer is surely "it depends", but there are a lot > > > of hardware vendors that target drivers to RHEL releases, which may > > > well make CentOS non-viable for hardware that doesn't have drivers > > > built in to the kernel. > > > > Generally if they follow the ABI guidelines I would expect it to work. > > Those are here: > https://access.redhat.com/articles/rhel8-abi-compatibility > > > > For loadable kernel modules there's a kernel ABI. > > Yes, and many things work well. My most recent issue was that kit > supplied by HPE (sorry, it's pain is stuck in my mind) had a RAID > controller that needs a driver disk during install - doing the install > time drivers is not a problem, the problem is that they don't support > CentOS, hence I had to use a RHEL driver and out of the 5 available for > RHEL7/8, only one of them worked with a CentOS release. HPE support > don't want to know because they don't support CentOS. > > I know this comes under the heading of "Corporate RedHat Policy", but > is RedHat going to do the right thing by CentOS 8 Stream to the level > of lobbying other behemoth corporations such as HPE or Dell to support > it? > As CentOS Stream grows, I expect many companies who sell hardware will become active members of the community. -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On Tue, Dec 8, 2020 at 6:00 PM Pete Biggs wrote: > The problem is that we won't know if it will work. When CentOS matched > the RHEL point releases we knew that an RPM/driver targeted for RHEL > 8.2 has a good chance of working on CentOS 8.2 - but that versioning > match is lost with Stream. So vendors will either have to produce > another version of their RPM for CentOS 8 Stream (and continuously > check to see if it needs to be updated) or, more likely, just not > bother to support CentOS. It already happens - HPE won't support > CentOS, but they do support RHEL and those RHEL RPMs work with CentOS. > The only Linux they support is RHEL, so we're stuck with our HPE kit. > Cool, I understand where you're coming from. If the world remained static after this announcement I would be more concerned about this scenario. As it is, we're in a dynamic space, and CentOS Stream will be a place that hardware vendors can participate as well. > But I will absolutely say that the things they are rolling into RHEL 8.4 > > in a few months are not inherently less stable or less secure or > > whatever else you want to call it .. when compared to other Linux > distros. > > So instead of keeping everything back for a point release, the packages > are set free once they are ready. Stream is a rolling release. And > that's fine, but it's not what people thought they were getting when > committing to CentOS. It has always been promoted as point release > compatible with RHEL and that was it's main attraction to many people. > It's certainly a change. > A separate question. Will a point release of RHEL 8.x be directly a > snapshot of 8Stream on a specific date? Or will RedHat pick and choose > which versions from 8Stream they put into 8.x? i.e. Would it be > possible to clone the 8Stream tree on the date that, say, 8.6 is > released and call it 8.6.stream - would 8.6 be the same as 8.6.stream > RHEL is developed according to a schedule that keeps us delivering minor releases on a 6 month cadence. That includes a period of time when we're putting the finishing touches on one release and simultaneously working on the next. Folks on the CentOS Stream team can speak with more authority on what the intended alignment points are (I know what makes sense from my perspective, but there may be other considerations I'm unaware of). -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On Tue, Dec 8, 2020 at 4:19 PM Pete Biggs wrote: > On Tue, 2020-12-08 at 17:54 -0500, Matthew Miller wrote: > > On Tue, Dec 08, 2020 at 03:15:17PM +, Pete Biggs wrote: > > > > "CentOS will become the developer playground" > > > > This one is categorically not the case. Even Fedora isn't a developer > > playground. Everything landing in CentOS Stream is actually *planned* > (with > > emphasis intentional) to go in a future RHEL release. > > It's all the talk of SIGs and developing and testing and that Stream > will be the centerpiece of that. That's what I meant. > I don't know if I'd call SIGs a playground, but they're certainly an important venue for communities to explore variations. > > Previously, all the development around RHEL releases was done in secret, > in > > the Red Hat black box. Now it's out of the box and can be watched. There > may > > be some launch pains, but I expect the average quality of an update > hitting > > CentOS Stream to be very high. > > I don't get that from the documents released today. If Stream is *not* > a test-bed, then surely the code that appears in Stream must be fully > formed in secret behind the scenes first. Yes, it will appear piecemeal > rather than in one big chunk, but it has been categorically denied that > Stream is not a RHEL 8.n+1 beta and is more a RHEL 8.n+1 RC/rolling > release. > I think maybe some of the nervousness about CentOS Stream comes from RHEL seeming opacity on its development model. As one of the architects of our development process I'd be happy to field questions. I'll start by making a two points in case they're in any way unclear: 1. Everything that goes into RHEL lands upstream first, then the patches are backported into the RHEL releases. 2. Most of the work we do or plan on doing is in bugzilla.redhat.com. If you go into the RHEL8 product queue today and file a bug you'll see "CentOS Stream" as a "Version" where an issue is encountered. I think what a lot of people are concerned about is the rolling-release > aspect of this. There will be no definitive versioning of CentOS in the > future - all you will be able to say is "fully updated" and it won't be > possible to slot a CentOS system in to exactly match a RHEL version. > Will third party RPMs built against RHEL 8.x be installable on a CentOS > 8 Stream system? The answer is surely "it depends", but there are a lot > of hardware vendors that target drivers to RHEL releases, which may > well make CentOS non-viable for hardware that doesn't have drivers > built in to the kernel. > Generally if they follow the ABI guidelines I would expect it to work. Those are here: https://access.redhat.com/articles/rhel8-abi-compatibility For loadable kernel modules there's a kernel ABI. > I suspect that for a large proportion of scenarios Streams will be > perfectly OK. But we still get software/instruments that specifically > say "only RHEL 7.4" or something like that (yes, it's a support > nightmare). It's regrettable when an ISV gets fixated on minor release versions and won't recognize forward compatibility. This is generally more of a matter of policy rooted in legacy than a technical limitation. -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 8 Public Beta Released
On 11/27/18 1:47 PM, Yan Li wrote: On 11/27/18 11:43 AM, Leon Fauster via CentOS wrote: Just wondering, are Software Collections on the trail of EOL now? Application Streams the new way to do? This answers my own question :-) https://developers.redhat.com/blog/2018/11/15/rhel8-introducing-appstreams/ Also this one: https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/ Being able to choose Python versions is great. Although I imagine that it will mean more work for our beloved CentOS buddies. The article title is a little misleading, so for those who don't have the time to read the full article and its references: There is no forced default python, but there are 3 different Pythons in RHEL 8 Beta: Platform-python: This is an off-to-the-side Python version for use by other RHEL 8 packages. Python 2.7: Offered as a module that can optionally be installed Python 3.6: Offered as a module that can optionally be installed The upshot is that RHEL 8 will be able to offer newer versions of Python in years to come, but end users can install the version that meets their needs and change the version over time as their needs change. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Would RHEL, CentOS, and Fedora Remain Open Source/Free Software After IBM Buys Red Hat for $34 Billion?
On 10/30/18 9:44 PM, Turritopsis Dohrnii Teo En Ming wrote: Good morning from Singapore, This is of paramount importance. Would Red Hat Enterprise Linux (RHEL), CentOS, and Fedora remain open source/free software after IBM buys Red Hat for $34 Billion? Remember that the sources to Fedora, RHEL, and CentOS are under a mixture of free (GPL sense) and open source licenses. The copyrights for almost all of these components are owned by the hundreds of thousands of people and organizations who contributed to them, not a single company. While none of us can predict the future, we do know that IBM has been a good partner in many parts of the open source world. They have made and continue to make key contributions to Linux and Fedora, and to open source in general, as cofounding members of the Open Innovation Network, an important entity that protects open source from patent trolls. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] IBM buying RedHat
On 10/29/18 1:55 AM, Simon Matter wrote: To me it seems like, if they are smart, they will try to push IBM POWER and RedHat Linux together to establish real competition in the hardware market again (and of course don't forget to keep Fedora/CentOS alive)! Er, RHEL has been running on Power for a very long time. The fastest supercomputer in the world is Power9 + RHEL. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upstream and downstream (was Re: What are the differences between systemd and non-systemd Linux distros?)
On Fri Oct 19 00:52:12 UTC 2018 Japheth Cleaver wrote: > This brings to mind a video I was pointed to not long ago of Brendan > Conoboy's talk at a Dojo recently: > > https://www.youtube.com/watch?v=HQsUdLPJW20 Hey, that's me! Hi. By the way, Jim Perrin did an updated version of this talk *today* at CERN in my absence (thanks Jim!). Hopefully the video will be posted soon. I expect we'll be doing updated versions of these at Devconf, future Dojos, etc- as things progress. > For quite a long time, many (perhaps most) folks had assumed that > Fedora functioned more or less directly as the internal alpha for > RHEL, with a branch at some point occurring, followed by pruning > of packages, hardening, vendor testing, and release. This is roughly true for new releases (plus or minus the kernel), but not for subsequent minor release updates. It is a shame because so much great work happens in Fedora between major RHEL releases. > Subsequently, > CentOS (even after the RH integration) functioned *strictly* as a > clean-room downstream rebuild, with the ability to do unsupported > things, like alternate architectures, or heavier kernels, restricted > to what could be done while maintaining a 100% binary compatible > rebuild. Any contributions back up where taken to be incidental, > from CentOS users reporting bugs that could be verified against RHEL. > > Conoboy, on the other hand, takes great pains during the speech to > describe a much more fluid and complex interaction between CentOS > and its upstream, and puts forth CentOS as a mechanism (perhaps > the best mechanism) for the winder EL community to contribute > (something?) back into RHEL's future. He also gives clear signals > that various Fedora steps have been in directions that Red Hat did > not want EL necessarily going, and that the simplistic assumptions > we've commonly been making aren't really correct. You might be reading into this more than is there. It's not so much that things are fluid as it is that they are undefined. There is no clear, consistent way for a member of the Fedora or CentOS communities, who create something great, to have that thing make its way into an update of an existing RHEL major release. Defining that path, making it possible, would be win for all. > Obviously, there seems to be a bit of a discrepancy there. > > The wider EL community is trapped between a rock and a hard place > somewhat. If you try to direct Fedora into the needs of EL users, > you stand a good chance of getting told to pound stand, and that > EL is getting in the way of bleeding-edge progress. Traditionally, > CentOS has had its hands tied since it aims to be 100% compatible > with upstream. Red Hat (and Red-Hat-as-a-sponsor-of-CentOS) might > do well to clarify just what type of back-and-forth it wants out of > the wider EL-using community. Does it want direct feedback in the > form of tickets? Should people form SIGs? Obviously RHEL7 is not > changing init systems, but where should one talk about the future? Man, it breaks my heart when I read things like this. There might be some historic truth to the above, but it doesn't have to be the future. The objective I mentioned near the end of the talk has been posted, but not yet voted on: https://fedoraproject.org/wiki/User:Pfrields/Lifecycle_Objective The beauty of community is that it can grow and shift according to the needs of its members. To me it looks like the lifecycle objective may be a partial answer to how Fedora, RHEL, and CentOS communities can reach a state of fluidity, a virtuous cycle. The thing that makes it the most likely to succeed is if members of the Fedora, RHEL, and CentOS communities work on it together. I hope those reading this who are interested in that join in. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
