Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
20/12/3 03:39(e)an, Dusty Mabe igorleak idatzi zuen: I 100% would like to get to a point where we rebase to the latest Fedora major soon after release. As jlebon mentioned earlier this does mean working harder to get ahead of the curve by adopting a rawhide development stream (not exposed to users) and taking more part in the Changes process. Why should we hide coreos rawhide stream? coreos rawhide should have standard rawhide's same exposition level imo. We don't public links on getfedora.org, but we allow anyone to use it just changing your repos, or directly installing it. Why not allow the same behaviour for coreos rawhide allowing to everyone to rebase to it? What's the benefit of hiding it from the public? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Mon, 07 Dec 2020 10:21:35 -0600 Michael Catanzaro wrote: > On Sat, Dec 5, 2020 at 7:33 am, James Szinger > wrote: > > Undelivered -devel packages and modularity are killer anti-features > > of EL 8—it is way too hard to build the software I need. > > Honestly I don't think modularity is a serious problem for end users. > Missing -devel packages is unbelievably frustrating, though. And EPEL > just doesn't contain as much as Fedora does, in general. I find the modularity end-user documentation to be woefully inadequate, especially for developers. > So for personal servers... well, I've never seen Fedora Server broken > by automatic updates. I don't think I would use Fedora Server for > critical business infrastructure, but it works well enough for my > personal needs. The odds of encountering problems with Fedora are > simply way lower than the odds of discovering that EPEL lacks > something that I want, or an essential -devel package that doesn't > exist. I have found updates to Fedora server software to be less disruptive than the desktop updates. I also find many small updates easier to manage than a few big updates. Our sysadmin at work spent most of 2020 updating the server fleet from CentOS 6 to CentOS 8. My software was easy to deal with since I develop and test on Fedora. A good test suite is essential. Jim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Mon, Dec 07, 2020 at 08:44:37AM -0700, Ken Dreyer wrote: > It's too early to say that this hypothetical workflow is a replacement for > Fedora. Things still show up in RHEL 8 ahead of CentOS Stream. I don't suggest that it's a replacement, but it can be complementary. > > A strong Fedora Server edition means a strong RHEL Server. Absolutely! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Mon, Dec 07, 2020 at 11:41:01AM +0100, p...@uni-bremen.de wrote: > Well, where should we discuss further proceedings? Is it this generic > devel list, is it ser...@lists.fedoraproject.org? Another one? Yes, let's take it to that list. Everyone interested, join us over there. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Sat, Dec 5, 2020 at 7:33 am, James Szinger wrote: Undelivered -devel packages and modularity are killer anti-features of EL 8—it is way too hard to build the software I need. Honestly I don't think modularity is a serious problem for end users. Missing -devel packages is unbelievably frustrating, though. And EPEL just doesn't contain as much as Fedora does, in general. So for personal servers... well, I've never seen Fedora Server broken by automatic updates. I don't think I would use Fedora Server for critical business infrastructure, but it works well enough for my personal needs. The odds of encountering problems with Fedora are simply way lower than the odds of discovering that EPEL lacks something that I want, or an essential -devel package that doesn't exist. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 4, 2020, 3:25 PM Matthew Miller wrote: > On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote: > > be a better-engineered and tested option. But as time goes on and > > the next EL release isn't either isn't announced or isn't stable > > enough to rely on, Fedora Server probably sees more use as a > > quasi-stable release base.. This fills a real need when your users > > are absolutely clamoring for things that aren't likely to be > > backported into the stable EL release and you don't want to have to > > send them into Ubuntu/Debian land (or have them grab an > > un-administered container off the shelf). > > Yeah, we may have an opportunity to do this better with CentOS Stream. > Starting with RHEL 8, there's no more "next EL isn't announced" -- instead, > they're every three years. So, we know when Fedora ELN is going to flow > into > CentOS Stream and from there to RHEL. We could actually position and label > each Fedora Server release by where it fits on the wave of that cadence. > It's too early to say that this hypothetical workflow is a replacement for Fedora. Things still show up in RHEL 8 ahead of CentOS Stream. A strong Fedora Server edition means a strong RHEL Server. - Ken > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
> Am 04.12.2020 um 20:33 schrieb Matthew Miller : > >> ... >> Just in case it is indeed considered useful and desirable I could >> contribute various Fedora Server related/specific documentations and >> how-to's, e.g. an annotated step-by-step guide to setup a basic server >> which can get extended for various purposes, how to set up a Postgres >> server on top of a basic server, an infrastructure for vm’s and containers >> (including scripts and ansible templates), troubleshooting guides, and >> other topics like that (mostly practical but always together with >> preliminary strategic considerations). Just let me know. > > > Absolutely! A functioning Working Group needs people interested in and doing > these kinds of things too, not just package maintenance. So if you're > interested, you'd absolutely be welcome in a re-constituted Fedora Server > WG. Well, where should we discuss further proceedings? Is it this generic devel list, is it ser...@lists.fedoraproject.org? Another one? First of all we need content, of course, but we also need some planning beforehand. - How to set things in motion, - where we want which documentation be published (under Releases, Quick Doc, dedicated area in https://docs.fedoraproject.org/en-US/docs/, or wiki entries at https://fedoraproject.org/wiki/Fedora_Project_Wiki?rd=Fedora_Project_Wiki/en), - where can drafts be discussed before publication, - contact with the Doc project to name but a few. > -- > Matthew Miller > > Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Sat, 5 Dec 2020 01:24:22 +0100 p...@uni-bremen.de wrote: > I see advantages sui generis in Fedora Server over CentOS, not "just" > an interim solution or workaround until the next CentOS version is > released. You get (almost) all the positive features that make CentOS > /RHEL stand out (well thought-out architecture and workflows, > security, systematic tools, etc.) and additionally > - more up-to-date application software, which often enables a better > response to current developments and changing requirements > - easier administration due to a greater variety of available packages > - shorter release jumps, which are therefore less disruptive > - easier (quasi rolling) updates (dnf update), which save a lot of > time > - Freedom from strict RH feature management (example BTRFS, XEN some > years ago) > - greater backwards hardware compatibility (e.g. exclusion of drivers > in el 8, which make some older hardware unusable or only very > difficult to use) > > The list can easily be extended. I totally agree. I used to use CentOS for server applications, but with the release of RHEL/CentOS 8, I’ve been moving toward Fedora. Undelivered -devel packages and modularity are killer anti-features of EL 8—it is way too hard to build the software I need. Whereas Fedora packages much more software, so I spend less time building dependencies, and the tooling is there to build what I need. With Fedora my salary goes more to adding value and less on reinventing the wheel. I don’t use Fedora Server directly. Instead I build container or VMs with a custom RPM set. The existence of Fedora Server Edition provides confidence that Fedora is a suitable and tested platform for server applications. Jim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
> Am 04.12.2020 um 23:16 schrieb Japheth Cleaver : > > On 12/4/2020 12:35 PM, Stephen John Smoogen wrote: >> >> ... >> >> For the people who were using it as servers, it was split between getting >> ready for the next RHEL/CentOS they would be deploying, they needed packages >> which were not in EPEL, or things like python/nodejs/etc was new enough for >> what they needed to run but wasn't in EL8. >> > It would be interesting to consider how Fedora Server use cases change over > time during an EL release cycle. > > For many server use cases where the box is NOT ephemeral, when CentOS and > Fedora are similar, it's likely that CentOS is going to be a > better-engineered and tested option. But as time goes on and the next EL > release isn't either isn't announced or isn't stable enough to rely on, > Fedora Server probably sees more use as a quasi-stable release base.. This > fills a real need when your users are absolutely clamoring for things that > aren't likely to be backported into the stable EL release and you don't > want to have to send them into Ubuntu/Debian land (or have them grab an > un-administered container off the shelf). Fedora has advantages not only when RHELx / CentOSx is matured, but in some cases already at release time, when some important components are already „behind“, e.g. postfix / dovecot with CentOS 8 regarding SNI and submission (which are quite important features in a containerised world). And with the current rapid development, even small version differences can be important. > In fact, Fedora Server as a "not EL, but better than nothing as a temporarily > stable platform" during these later periods could be a useful niche to fill. > Bonus points for some of those extended support duration/stable discussions > from a few years ago. I see advantages sui generis in Fedora Server over CentOS, not "just" an interim solution or workaround until the next CentOS version is released. You get (almost) all the positive features that make CentOS /RHEL stand out (well thought-out architecture and workflows, security, systematic tools, etc.) and additionally - more up-to-date application software, which often enables a better response to current developments and changing requirements - easier administration due to a greater variety of available packages - shorter release jumps, which are therefore less disruptive - easier (quasi rolling) updates (dnf update), which save a lot of time - Freedom from strict RH feature management (example BTRFS, XEN some years ago) - greater backwards hardware compatibility (e.g. exclusion of drivers in el 8, which make some older hardware unusable or only very difficult to use) The list can easily be extended. -- Dr. Peter Boy p...@boy-digital.de p...@uni-bremen.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
> Am 04.12.2020 um 20:33 schrieb Matthew Miller : > > On Fri, Dec 04, 2020 at 07:53:12PM +0100, p...@uni-bremen.de wrote: >> Just in case it is indeed considered useful and desirable I could >> contribute various Fedora Server related/specific documentations and >> how-to's, e.g. an annotated step-by-step guide to setup a basic server >> which can get extended for various purposes, how to set up a Postgres >> server on top of a basic server, an infrastructure for vm’s and containers >> (including scripts and ansible templates), troubleshooting guides, and >> other topics like that (mostly practical but always together with >> preliminary strategic considerations). Just let me know. > > > Absolutely! A functioning Working Group needs people interested in and doing > these kinds of things too, not just package maintenance. So if you're > interested, you'd absolutely be welcome in a re-constituted Fedora Server > WG. OK, I would like to participate and contribute to the documentary side. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On 12/3/20 1:01 PM, Miroslav Suchý wrote: Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a): Mostly the latter. I don't even really care if they end up keeping the distinct os-release and etc. Is this backed by some numbers and analysis? My personal usage is that I create **hundred thousands** VM from Fedora cloud image per year. And I use one or two netinstall images to deploy new home server for me or friend. And one or two runnable images when I persuade someone to try Fedora. Cloud image clearly wins the number by orders of magnitude. But without the later we do not get the penetration and new users. And no one willing to use cloud images. I think you snipped too much and misunderstood the meaning. My understanding is that Matthew is suggesting to merge the cloud and server editions into one thing and there doesn't need to be a distinct os-release for both of them. e.g. the "cloud" has the "server" os-release and is just a differently packaged version of the server edition. He's not saying that one or the other will go away. There just needs to be different marketing of the cloud packaged server edition. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote: > be a better-engineered and tested option. But as time goes on and > the next EL release isn't either isn't announced or isn't stable > enough to rely on, Fedora Server probably sees more use as a > quasi-stable release base.. This fills a real need when your users > are absolutely clamoring for things that aren't likely to be > backported into the stable EL release and you don't want to have to > send them into Ubuntu/Debian land (or have them grab an > un-administered container off the shelf). Yeah, we may have an opportunity to do this better with CentOS Stream. Starting with RHEL 8, there's no more "next EL isn't announced" -- instead, they're every three years. So, we know when Fedora ELN is going to flow into CentOS Stream and from there to RHEL. We could actually position and label each Fedora Server release by where it fits on the wave of that cadence. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On 12/4/2020 12:35 PM, Stephen John Smoogen wrote: Anecdata which is as 'useful' as any other. Most of the people I have dealt with in the last 4 years with Server have been using it mainly as a replacement for the Everything DVD and because it was the most 'un-opinionated' release of Fedora. It wasn't actually being used in any more of a server release as much as a 'get out of my way' while still using Fedora. For the people who were using it as servers, it was split between getting ready for the next RHEL/CentOS they would be deploying, they needed packages which were not in EPEL, or things like python/nodejs/etc was new enough for what they needed to run but wasn't in EL8. It would be interesting to consider how Fedora Server use cases change over time during an EL release cycle. For many server use cases where the box is NOT ephemeral, when CentOS and Fedora are similar, it's likely that CentOS is going to be a better-engineered and tested option. But as time goes on and the next EL release isn't either isn't announced or isn't stable enough to rely on, Fedora Server probably sees more use as a quasi-stable release base.. This fills a real need when your users are absolutely clamoring for things that aren't likely to be backported into the stable EL release and you don't want to have to send them into Ubuntu/Debian land (or have them grab an un-administered container off the shelf). In fact, Fedora Server as a "not EL, but better than nothing as a temporarily stable platform" during these later periods could be a useful niche to fill. Bonus points for some of those extended support duration/stable discussions from a few years ago. Ultimately, however, I feel like the use case of Fedora Server is inexorably tied to the RHEL/CentOS (or CentOS Stream) discussions. And a Fedora WG that tries to do long-term planning and positioning needs to be part of those overall discussions for the greater good of the RedHat ecosystem. Short term marketing is fine, but the different sides of RedHat need to be on the same page about this all. -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
Am 04.12.20 um 21:35 schrieb Stephen John Smoogen: Anecdata which is as 'useful' as any other. just some additional experience from my side: - Fedora provides a recent PHP (unlike RHEL 7) but also ships the full PHP stack required to run popular PHP applications like WordPress/NextCloud/... AFAIK due to modularity and build-only RPMs it is still quite hard (on RHEL 8) to get PHP-related rpms required to deploy these PHP applications. With Fedora it works like a breeze. - Fedora works well, no breaking updates in our server use - also a lot of recent tech available: wireguard, systemd daemons Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Friday, 04 December 2020 at 20:51, Josh Boyer wrote: [...] > For those using it for traditional server use cases, why? What about > it do you find better than something like CentOS? Here are my reasons, in no particular order: 1. Because that's what I use on my desktops. 2. Because latest software versions. 3. Because I don't have to maintain all the packages I'm interested in for EPEL, too. 4. Because it works so well. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, 4 Dec 2020 at 15:17, Matthew Miller wrote: > On Fri, Dec 04, 2020 at 02:51:45PM -0500, Josh Boyer wrote: > > It would be interesting if we had a set of use cases Fedora Server > > actually solves. So far in this thread we've seen people use it, but > > it reads to me like they use it to get a boiled down installation of > > Fedora. So is Fedora Server just a convenient way to get a quick and > > simple Fedora installation (e.g. you're using it because it's > > *Fedora*), or do people actually use it for traditional server use > > cases. > > > > For those using it for traditional server use cases, why? What about > > it do you find better than something like CentOS? > > Yeah, this is absolutely another valuable idea. The Use Cases and Personas > at > https://fedoraproject.org/wiki/Server/Product_Requirements_Document#User_Profiles.2C_Primary_Use_Cases_and_Goals > were created *seven* years ago and reflect aspiration, not nessarily > reality. So it would be very valuable for interested people to update that > to reflect both actual current use and the current aspirations. > > > Anecdata which is as 'useful' as any other. Most of the people I have dealt with in the last 4 years with Server have been using it mainly as a replacement for the Everything DVD and because it was the most 'un-opinionated' release of Fedora. It wasn't actually being used in any more of a server release as much as a 'get out of my way' while still using Fedora. For the people who were using it as servers, it was split between getting ready for the next RHEL/CentOS they would be deploying, they needed packages which were not in EPEL, or things like python/nodejs/etc was new enough for what they needed to run but wasn't in EL8. > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 04, 2020 at 02:51:45PM -0500, Josh Boyer wrote: > It would be interesting if we had a set of use cases Fedora Server > actually solves. So far in this thread we've seen people use it, but > it reads to me like they use it to get a boiled down installation of > Fedora. So is Fedora Server just a convenient way to get a quick and > simple Fedora installation (e.g. you're using it because it's > *Fedora*), or do people actually use it for traditional server use > cases. > > For those using it for traditional server use cases, why? What about > it do you find better than something like CentOS? Yeah, this is absolutely another valuable idea. The Use Cases and Personas at https://fedoraproject.org/wiki/Server/Product_Requirements_Document#User_Profiles.2C_Primary_Use_Cases_and_Goals were created *seven* years ago and reflect aspiration, not nessarily reality. So it would be very valuable for interested people to update that to reflect both actual current use and the current aspirations. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 4, 2020 at 2:33 PM Matthew Miller wrote: > > On Fri, Dec 04, 2020 at 07:53:12PM +0100, p...@uni-bremen.de wrote: > > I’m not a maintainer but I use Fedora Server for a lot of our university > > research institutions infrastructure (and I’m a dormant member of Fedora > > docs). > > > > Just in case it is indeed considered useful and desirable I could > > contribute various Fedora Server related/specific documentations and > > how-to's, e.g. an annotated step-by-step guide to setup a basic server > > which can get extended for various purposes, how to set up a Postgres > > server on top of a basic server, an infrastructure for vm’s and containers > > (including scripts and ansible templates), troubleshooting guides, and > > other topics like that (mostly practical but always together with > > preliminary strategic considerations). Just let me know. > > > Absolutely! A functioning Working Group needs people interested in and doing > these kinds of things too, not just package maintenance. So if you're > interested, you'd absolutely be welcome in a re-constituted Fedora Server > WG. It would be interesting if we had a set of use cases Fedora Server actually solves. So far in this thread we've seen people use it, but it reads to me like they use it to get a boiled down installation of Fedora. So is Fedora Server just a convenient way to get a quick and simple Fedora installation (e.g. you're using it because it's *Fedora*), or do people actually use it for traditional server use cases. For those using it for traditional server use cases, why? What about it do you find better than something like CentOS? josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 04, 2020 at 07:53:12PM +0100, p...@uni-bremen.de wrote: > I’m not a maintainer but I use Fedora Server for a lot of our university > research institutions infrastructure (and I’m a dormant member of Fedora > docs). > > Just in case it is indeed considered useful and desirable I could > contribute various Fedora Server related/specific documentations and > how-to's, e.g. an annotated step-by-step guide to setup a basic server > which can get extended for various purposes, how to set up a Postgres > server on top of a basic server, an infrastructure for vm’s and containers > (including scripts and ansible templates), troubleshooting guides, and > other topics like that (mostly practical but always together with > preliminary strategic considerations). Just let me know. Absolutely! A functioning Working Group needs people interested in and doing these kinds of things too, not just package maintenance. So if you're interested, you'd absolutely be welcome in a re-constituted Fedora Server WG. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
> Am 04.12.2020 um 19:08 schrieb Matthew Miller : > > It's not a matter of making changes for change's own sake, but I would hope > that we'd have some level of innovation and experimentation in Fedora > Server. There are also just normal things like marketing materials, > promotion, blog posts, docs, etc., that can use ongoing work. > I’m not a maintainer but I use Fedora Server for a lot of our university research institutions infrastructure (and I’m a dormant member of Fedora docs). Just in case it is indeed considered useful and desirable I could contribute various Fedora Server related/specific documentations and how-to's, e.g. an annotated step-by-step guide to setup a basic server which can get extended for various purposes, how to set up a Postgres server on top of a basic server, an infrastructure for vm’s and containers (including scripts and ansible templates), troubleshooting guides, and other topics like that (mostly practical but always together with preliminary strategic considerations). Just let me know. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 04, 2020 at 11:59:17AM -0500, Neal Gompa wrote: > > No one is talking about making it go away, just de-editioning it. I'd > > definitely prefer it to remain an edition, but we need it to be more active > > for that to work. > Having an active team is one thing, but making changes just because is > quite another. I don't feel it's worth demoting Fedora Server (just > like I didn't like what happened to Fedora Cloud way back when with > Atomic). But if you need me to be there to keep the WG going so it > doesn't get demoted, I'm happy to help shepherd it. It's not a matter of making changes for change's own sake, but I would hope that we'd have some level of innovation and experimentation in Fedora Server. There are also just normal things like marketing materials, promotion, blog posts, docs, etc., that can use ongoing work. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
I'm not part of the server WG, but a super interested user. Count me in to help if needed. Br, El vie, 4 dic 2020 a las 14:00, Neal Gompa () escribió: > On Fri, Dec 4, 2020 at 11:49 AM Matthew Miller > wrote: > > > > On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote: > > > I agree, sign me up! I've been using Fedora Server for years for my > > > own projects and it's been 99.9% flawless, so I would be sad if it > > > went away. > > > > No one is talking about making it go away, just de-editioning it. I'd > > definitely prefer it to remain an edition, but we need it to be more > active > > for that to work. > > > > Having an active team is one thing, but making changes just because is > quite another. I don't feel it's worth demoting Fedora Server (just > like I didn't like what happened to Fedora Cloud way back when with > Atomic). But if you need me to be there to keep the WG going so it > doesn't get demoted, I'm happy to help shepherd it. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Eduard Lucena Móvil: +56962318010 GNU/Linux User #589060 Ubuntu User #8749 Fedora Marketing Representative ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 4, 2020 at 11:49 AM Matthew Miller wrote: > > On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote: > > I agree, sign me up! I've been using Fedora Server for years for my > > own projects and it's been 99.9% flawless, so I would be sad if it > > went away. > > No one is talking about making it go away, just de-editioning it. I'd > definitely prefer it to remain an edition, but we need it to be more active > for that to work. > Having an active team is one thing, but making changes just because is quite another. I don't feel it's worth demoting Fedora Server (just like I didn't like what happened to Fedora Cloud way back when with Atomic). But if you need me to be there to keep the WG going so it doesn't get demoted, I'm happy to help shepherd it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote: > I agree, sign me up! I've been using Fedora Server for years for my > own projects and it's been 99.9% flawless, so I would be sad if it > went away. No one is talking about making it go away, just de-editioning it. I'd definitely prefer it to remain an edition, but we need it to be more active for that to work. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Wed, Dec 2, 2020 at 6:48 PM Ben Cotton wrote: > > On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote: > > > There were a number of people interested in helping with reviving the > > Server WG, myself included. But we don't know how to have that move > > forward. We've never really had a situation like this before... > > > I'd start with staging a takeover of https://fedoraproject.org/wiki/Server > > It looks like there are no meeting logs in the last two years, so I > don't think you'll get much pushback. > > I talked to sgallagh before posing this question, so I don't expect > you'll get any pushback. If anything, you'll probably make people > happy. :-) I agree, sign me up! I've been using Fedora Server for years for my own projects and it's been 99.9% flawless, so I would be sad if it went away. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 3 Dec 2020 at 20:42, Adam Williamson wrote: > On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote: > > > > I think if we don't want to accept a different > > > > philosophy about release schedule and release engineering we can > > just > > > close > > > > that Change proposal. > > > > > > That's not the outcome I intended, but rather that if we want > > CoreOS to > > > be an "Edition" but we don't want to require it to conform to the > > > existing "philosophy", as you put it, we need the scope of this > > Change > > > to include thinking through all the consequences of that and > > deciding > > > what to do about them. > > > > > > > Happy to do that, is your main concern about communication and the > > story of > > what is "Fedora" ? or what are the other consequences ? > > For me personally it's mainly about validation and release engineering. > Specifically, making sure the processes we have in place for deciding > when to cut a CoreOS release in a stream and when to bump streams > between releases align with the Fedora-wide release criteria etc, and > making sure the release criteria express all the requirements we > actually intend to have for making those choices as regards CoreOS. > Making sure there's a clear vertically-integrated process, like there > is for "Fedora", from Edition PRDs to release criteria to validation > tests to release decisions, and there are all the necessary bits of > glue in between those layers, so you can pretty easily trace back and > forth between them. > > But I suspect there are various consequences for other teams and other > parts of the process, if you think about it. If you just look at a > Fedora release schedule: > > https://fedorapeople.org/groups/schedule/f-34/f-34-all-tasks.html > > there are a zillion things on there, and they're all aligned to our big > every-six-month-release-machine somehow. At minimum, it'd be a good > idea to look through all those and think about whether and how each > entry would be affected by having an Edition with a completely > different release process. > Ok I think I can improve the Change proposal along these lines, and start with what is currently done for each FCOS release and also how that fits within the schedule. > > > > More or less, yes - but with a key addition: "...and if so, how?" > > > > > > > I feel that we already have the how, Fedora CoreOS has been releasing > > fortnightly for more than a year now. > > So it is a matter of making more widely known how this is done ? > > It's a matter of "how" from the perspective of the Fedora project. I > just meant it as an expression of all the other stuff above. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 3 Dec 2020 at 20:32, Adam Williamson wrote: > On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote: > > > [big snip] > > > To the outside > > > world, there is a strong impression that the thing called "Fedora" is a > > > product or set of products with a release number that gets released > > > every six months. The concept of "Fedora 33 release" or "Fedora 34 > > > release" is a strong concept with all these sort of institutional > > > ripples. > > > > > > > And why cannot we make this evolve ? Is it bad to have a Fedora that has > > streams instead of versions ? > > We can. > > Can I ask that you please read my *whole* emails before writing your > replies? Or at least if you must reply in-line while reading, please > after you finish, go back and see if what you wrote earlier still > applies? All of this stuff up top is irrelevant because it's all based > on an assumption that I was saying FCOS must at all costs align with > existing processes and schedules, when I was not saying that at all. I > was just trying to outline the situation and the factors that need to > be considered. > Sorry if that came down that way, but I was trying to get a better understanding of your concerns. I ll try to do better next time :-) > > I'll reply to the stuff from lower down, where you actually engaged > with what I was actually saying, in a separate mail. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
> Am 03.12.2020 um 20:35 schrieb Alexander Bokovoy : > > On to, 03 joulu 2020, Matthew Miller wrote: >> On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote: >>> I suppose we could look into this, but it seems kind of complementary to >>> me: >>> Server: a install dvd, pxe/netboot >>> Cloud: a runnable image >>> Are folks wanting to drop the dvd and netinstall? >>> Or just market the Cloud image more to server admins that want a ready >>> to run image? >> >> Mostly the latter. I don't even really care if they end up keeping the >> distinct os-release and etc. > > I do care about being able to deploy from DVD or pxe/netboot. For home > environments cloud images are not everything you need, especially for > home infrastructure. FreeIPA on Fedora is one of practical home > infrastructure deployment targets. Hot only home environments! At least very many companies of all sizes have local server infrastructure and many cannot or do not want to rely on the cloud alone. I very much hope that the Fedora project does not fall for hype. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 3, 2020, 4:11 PM Colin Walters wrote: > > > On Thu, Dec 3, 2020, at 2:14 PM, Josh Boyer wrote: > > > This seems more split on the OS consumption model to me, rather than > > the tools to make it. The end user shouldn't care at all about what > > tools make it. > > I've been meaning to write a longer blog post on this but briefly: > > How you build software gets very entangled with how you ship it, and how > you ship it gets entangled with how users consume and manage it. It's > really this dynamic that has created so much inertia around traditional > dpkg/rpm/etc., and also is already happening in the container ecosystem too > around Kubernetes (the fact you don't do in-place updates there but > schedule a new pod deeply impacts configuration/management). > Yes. > The fact that FCOS releases are uniform and constant and biweekly feeds > into a whole lot of things across that stack. The concept of a "stream" > was brought up and that's quite central too, along with the Cincinnati > staged rollout system. > Also yes! > > They just want to install their OS and keep it updated > > and have those updates NOT BREAK their systems or apps. ostree based > > OS updates have some inherent benefits that a per-package update model > > lacks and I find it intriguing because you could test a whole OS > > update stack to at least ensure it's consistent within itself. > > Not "could" - that's the basis of our technology stack and how we think > and operate. > Right. It's not a property inherent to the tool you use to build though. "Could" means something else could do that as well. > > Whether that happens or not is up to the creators of the OS. You can > > do the same with bodhi but we... don't. Neither set of tools can > > really claim to validate the updates won't break third party apps > > though. > > We expect applications run as containers. > There are still interfaces between the container and the host. They can still break things. I do agree that ostree and the deployment model coreos is using as a host has really good mitigation for application stability though. Outside of that, if one were to run applications directly on the host, there is a larger surface area that can break. I think it is interesting to see what enterprise distros accomplish around this problem and where they fall down. Fedora is even further away in this regard, but that's a conscious choice of the project. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 3, 2020, at 2:14 PM, Josh Boyer wrote: > This seems more split on the OS consumption model to me, rather than > the tools to make it. The end user shouldn't care at all about what > tools make it. I've been meaning to write a longer blog post on this but briefly: How you build software gets very entangled with how you ship it, and how you ship it gets entangled with how users consume and manage it. It's really this dynamic that has created so much inertia around traditional dpkg/rpm/etc., and also is already happening in the container ecosystem too around Kubernetes (the fact you don't do in-place updates there but schedule a new pod deeply impacts configuration/management). The fact that FCOS releases are uniform and constant and biweekly feeds into a whole lot of things across that stack. The concept of a "stream" was brought up and that's quite central too, along with the Cincinnati staged rollout system. > They just want to install their OS and keep it updated > and have those updates NOT BREAK their systems or apps. ostree based > OS updates have some inherent benefits that a per-package update model > lacks and I find it intriguing because you could test a whole OS > update stack to at least ensure it's consistent within itself. Not "could" - that's the basis of our technology stack and how we think and operate. > Whether that happens or not is up to the creators of the OS. You can > do the same with bodhi but we... don't. Neither set of tools can > really claim to validate the updates won't break third party apps > though. We expect applications run as containers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a): > Mostly the latter. I don't even really care if they end up keeping the > distinct os-release and etc. Is this backed by some numbers and analysis? My personal usage is that I create **hundred thousands** VM from Fedora cloud image per year. And I use one or two netinstall images to deploy new home server for me or friend. And one or two runnable images when I persuade someone to try Fedora. Cloud image clearly wins the number by orders of magnitude. But without the later we do not get the penetration and new users. And no one willing to use cloud images. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Wed, Dec 2, 2020 at 12:52 PM Ben Cotton wrote: > > On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote: > > > There were a number of people interested in helping with reviving the > > Server WG, myself included. But we don't know how to have that move > > forward. We've never really had a situation like this before... > > > I'd start with staging a takeover of https://fedoraproject.org/wiki/Server > > It looks like there are no meeting logs in the last two years, so I > don't think you'll get much pushback. > > I talked to sgallagh before posing this question, so I don't expect > you'll get any pushback. If anything, you'll probably make people > happy. :-) > > On Wed, Dec 2, 2020 at 12:30 PM Adam Williamson > wrote: > > > > I'm not sure it's really warranted, to be honest. A counterpoint is > > that you can consider Server to be sort of dormant *because it works*. > > Is "it still works" sufficient to keep a deliverable at the forefront? > Obviously we want what we ship to work, whether it's an Edition or > bex's Llama Herder Lab. But what is Server doing to move the state of > the art forward? Server is a slightly different case in that generally > you don't want servers to be too adventurous, but if it's in statis, > should it be a flagship? > > Like I said above, the Server WG appears to be in zombie state for at > least the last two years. Is Fedora Server doing what it should be > doing now, or is it doing what it should have done two years ago? IMO, yes. I am a silent consumer of it. It provides a non-graphical default Fedora installation that just works as a target for various automated deployments (e.g., qemu + ansible). For both work and non-work deployments of Fedora on VMs, Fedora Server is my default mechanism to do so (whether on local libvirt or remote cloud deployments). I'm not sure it really needs much care and feeding -- a boring packaging of Fedora with some bare necessities and without any graphical tooling doesn't need much management or steering. Changing what is shipped in the base Server distribution frequently is an anti-feature. That I haven't had any Server-specific bugs or issues is a good thing. > > Of course, we can keep publishing Server images and providing those > > capabilities without calling it an Edition, but...I'm not sure it just > > being sort of quiet and undramatic necessarily merits that, especially > > if we don't have clear replacements for its capabilities yet. > > I'm certainly not advocating we drop Server entirely. But we should > evaluate its place in Fedora, particularly if there's no one providing > active care and feeding. I'd much rather see the Server WG come back > to life and keep it as an Edition. The care and feeding of a Fedora Server edition, IMO, shouldn't come from changes in content curation, but all the packagers involved in maintenance of packages shipped by the edition. My 2c. Alex > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 15:22 -0500, Colin Walters wrote: > > On Thu, Dec 3, 2020, at 2:48 PM, Adam Williamson wrote: > > > I dunno when's the last time anyone tried without it, tbh. > > For CoreOS we spent a *lot* of time ensuring that Ignition has first class > SELinux support, and actually making it work on the Live ISO in a > not-horribly-hacky way required a kernel patch: > https://lore.kernel.org/selinux/20190912133007.27545-1-jle...@redhat.com/T/#u I meant for the anaconda-based liveinst, not for ignition... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 3, 2020, at 2:48 PM, Adam Williamson wrote: > I dunno when's the last time anyone tried without it, tbh. For CoreOS we spent a *lot* of time ensuring that Ignition has first class SELinux support, and actually making it work on the Live ISO in a not-horribly-hacky way required a kernel patch: https://lore.kernel.org/selinux/20190912133007.27545-1-jle...@redhat.com/T/#u Also related to the installer experience, note that because the installer ISO is the same thing as the OS, we ship `podman` and so it's fully supported to use Ignition to run containers before/after the install. And this is all really part of the story that a benefit of Ignition (in taking the role of both cloud-init and kickstart compared to traditional Fedora) is that we have a very consistent, uniform approach to provisioning/configuring the operating system that applies across cloud, on-premise metal etc. Also, because our installer environment *is* the OS, you also have `podman` there...so running containers before/during/after the install is natural and encouraged. This OpenShift enhancement covers a lot of this: https://github.com/openshift/enhancements/blob/master/enhancements/rhcos/liveisoinstall.md (Which is relevant here because the Live ISO in FCOS happened after RHCOS 4.1 shipped; before that we had a hacky shell script in a minimal initramfs) We are just constantly testing that flow (actually every PR to coreos-assembler, plus it gates FCOS releases) which particularly compared to Anaconda is massively simplified because there's no custom GUI involved. Related to testing, we actually didn't touch on the whole topic that FCOS is fairly Github oriented. I did a blog related to this, https://blog.verbum.org/2020/12/03/still-on-github/ Our release workflow involves submitting PRs which get tested just like other PRs and run through the same test suite. And on that topic, coreos-assembler contains not just *build* tooling but also *testing* tooling. Our single (yeah it's big) container image has everything you need to run all our build *and* tests as a single versioned unit, which runs completely as non-root with unprivileged podman; no need to touch the host (or for that matter, depend on Fedora as the host system at all, though the container is Fedora based the current pipeline uses RHCOS). Hm well I was just trying to talk about Ignition and SELinux but more ended up here =) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 14:43 -0500, Matthew Miller wrote: > On Thu, Dec 03, 2020 at 11:36:32AM -0800, Adam Williamson wrote: > > > > (Personally I'm really proud that for example our Live ISO ships with > > > > SELinux enforcing) > > > This is true of Fedora Workstation and other desktop spin live ISOs as > > > well. > > Yes, but the live installer runs 'setenforce 0' at the start then sets > > it back on exit. As long as the live installer is running, you're in > > permissive. > > Huh. Well, then, that's cool that CoreOS doesn't need to do that. > > Does the live installer really? I dunno when's the last time anyone tried without it, tbh. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 14:14 -0500, Josh Boyer wrote: > > > > Beyond the pungi-vs-bodhi thing of course, to me it is also very > > fundamental that our OS build and test process runs natively via podman and > > Kubernetes (unprivileged). We're telling people to use containers; > > building the operating system shouldn't require you to `yum install` (or > > even `rpm-ostree` install stuff directly on a host system. Our current > > build pipeline is Jenkins-running-in-OpenShift; we're actively working on > > removing Jenkins from the equation in some circumstances and making the > > whole thing even more Kubernetes-native. This is not at all true of the > > Koji/pungi stack. > > Is that difference really split along tooling lines? I'm not sure it > is. You could use pungi to build updated installation media every > time there's a push of updates. We just... don't. Right. It's a choice, not a capability thing. At this point I think there are two reasons for the choice: 1) It *does* take a long time to produce a full compose, and doing that for every update push for every stable release might overwhelm capacity, I think 2) We don't have the capacity to test full composes very frequently to the level we test "stable releases" 2 is really the awkward one. It's not really a showstopper, but it comes with awkward questions. We could respin every month and go through a full validation process, but that would be a huge lift and eat up basically the whole of QA's time (and probably a lot of releng's, and various other people) and we'd probably still miss stuff. We could produce respins on some sort of schedule and run them through automated testing and maybe some light manual validation and put them out on some kind of "use at your own risk" basis, but there the devil is in the details, particularly of communication. How exactly do you sell the message "these images are PROBABLY actually a bit better than the release ones, and they're almost certainly more secure, but we can't really entirely stand behind them and if you have some problem with them we're going to tell you to use the official release image instead"? It's a tricky bit of communication to do successfully. Even still, we might want to try it. I dunno. But at that point we've gone a bit off the original topic, and there I think Colin hit the nail on the head with "for FCOS we made a massive simplification". Which is a nice thing to be able to do ;) For the thing called "Fedora", we can't really make all those simplifications, because of existing expectations and commitments. So this goes back to my big point: when we make "Fedora CoreOS" a key part of the thing called "Fedora", we have impedance mismatches, and here's another. The thing called "Fedora CoreOS" has made these simplifications in deployment: it's massively restricted what "deployment" means, in terms of what gets deployed where and how. That gives it quite a big payoff in various ways in terms of how development and testing and release can be done. But we really don't have those options for the whole of the thing called "Fedora", not on any sensible timescale at least. Unless Josh wants to start getting really radical about RHEL 9...:D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 03, 2020 at 11:36:32AM -0800, Adam Williamson wrote: > > > (Personally I'm really proud that for example our Live ISO ships with > > > SELinux enforcing) > > This is true of Fedora Workstation and other desktop spin live ISOs as well. > Yes, but the live installer runs 'setenforce 0' at the start then sets > it back on exit. As long as the live installer is running, you're in > permissive. Huh. Well, then, that's cool that CoreOS doesn't need to do that. Does the live installer really? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On Thu, Dec 03, 2020 at 09:35:02PM +0200, Alexander Bokovoy wrote: > >>Server: a install dvd, pxe/netboot > >>Cloud: a runnable image > >>Are folks wanting to drop the dvd and netinstall? > >>Or just market the Cloud image more to server admins that want a ready > >>to run image? > > > >Mostly the latter. I don't even really care if they end up keeping the > >distinct os-release and etc. > > I do care about being able to deploy from DVD or pxe/netboot. For home > environments cloud images are not everything you need, especially for > home infrastructure. FreeIPA on Fedora is one of practical home > infrastructure deployment targets. Right, let me be clear: I think we need all of these things, and I think it's best if we have one Edition that covers the different deployment scenarios. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 14:06 -0500, Matthew Miller wrote: > On Thu, Dec 03, 2020 at 01:58:56PM -0500, Colin Walters wrote: > > (Personally I'm really proud that for example our Live ISO ships with > > SELinux enforcing) > > This is true of Fedora Workstation and other desktop spin live ISOs as well. Yes, but the live installer runs 'setenforce 0' at the start then sets it back on exit. As long as the live installer is running, you're in permissive. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On to, 03 joulu 2020, Matthew Miller wrote: On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote: I suppose we could look into this, but it seems kind of complementary to me: Server: a install dvd, pxe/netboot Cloud: a runnable image Are folks wanting to drop the dvd and netinstall? Or just market the Cloud image more to server admins that want a ready to run image? Mostly the latter. I don't even really care if they end up keeping the distinct os-release and etc. I do care about being able to deploy from DVD or pxe/netboot. For home environments cloud images are not everything you need, especially for home infrastructure. FreeIPA on Fedora is one of practical home infrastructure deployment targets. The linux-system-roles is it's own project... so I am not sure what the working group would do here? Help them? Help them, and help make it feel like a primary feature of Fedora Server. Right now, our marketing materials at https://getfedora.org/en/server/ highlight: * modularity * cockpit * FreeIPA -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote: > > > I think if we don't want to accept a different > > > philosophy about release schedule and release engineering we can > just > > close > > > that Change proposal. > > > > That's not the outcome I intended, but rather that if we want > CoreOS to > > be an "Edition" but we don't want to require it to conform to the > > existing "philosophy", as you put it, we need the scope of this > Change > > to include thinking through all the consequences of that and > deciding > > what to do about them. > > > > Happy to do that, is your main concern about communication and the > story of > what is "Fedora" ? or what are the other consequences ? For me personally it's mainly about validation and release engineering. Specifically, making sure the processes we have in place for deciding when to cut a CoreOS release in a stream and when to bump streams between releases align with the Fedora-wide release criteria etc, and making sure the release criteria express all the requirements we actually intend to have for making those choices as regards CoreOS. Making sure there's a clear vertically-integrated process, like there is for "Fedora", from Edition PRDs to release criteria to validation tests to release decisions, and there are all the necessary bits of glue in between those layers, so you can pretty easily trace back and forth between them. But I suspect there are various consequences for other teams and other parts of the process, if you think about it. If you just look at a Fedora release schedule: https://fedorapeople.org/groups/schedule/f-34/f-34-all-tasks.html there are a zillion things on there, and they're all aligned to our big every-six-month-release-machine somehow. At minimum, it'd be a good idea to look through all those and think about whether and how each entry would be affected by having an Edition with a completely different release process. > > More or less, yes - but with a key addition: "...and if so, how?" > > > > I feel that we already have the how, Fedora CoreOS has been releasing > fortnightly for more than a year now. > So it is a matter of making more widely known how this is done ? It's a matter of "how" from the perspective of the Fedora project. I just meant it as an expression of all the other stuff above. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote: [big snip] > To the outside > > world, there is a strong impression that the thing called "Fedora" is a > > product or set of products with a release number that gets released > > every six months. The concept of "Fedora 33 release" or "Fedora 34 > > release" is a strong concept with all these sort of institutional > > ripples. > > > > And why cannot we make this evolve ? Is it bad to have a Fedora that has > streams instead of versions ? We can. Can I ask that you please read my *whole* emails before writing your replies? Or at least if you must reply in-line while reading, please after you finish, go back and see if what you wrote earlier still applies? All of this stuff up top is irrelevant because it's all based on an assumption that I was saying FCOS must at all costs align with existing processes and schedules, when I was not saying that at all. I was just trying to outline the situation and the factors that need to be considered. I'll reply to the stuff from lower down, where you actually engaged with what I was actually saying, in a separate mail. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 3, 2020 at 1:59 PM Colin Walters wrote: > > On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote: > > > > > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > > the context of how CoreOS is built and released? What set of bits will > > we be deciding to ship or not ship, and how will that have been decided > > and communicated? Where will we look to find the test results and > > criteria on which we would base that decision? > > There are a whole lot of aspects to this, but one angle to look at this from > is that I personally have always thought the way Fedora uses pungi up until > releases and everything's about a "compose" and then it switches to a Bodhi > wild west where updates are unversioned things that can release at any > time...well, it doesn't make much sense. > > The concept that you have boot media that can reach 6 months old is a very > bad anti-pattern because there are often periods of time where the software > there has security vulnerabilities. *Particularly* for a desktop system > starting up a 6 month old web browser is just actively dangerous. > > Now I understand there are reasons traditional Fedora does this - among them > that Anaconda is a huge thing on its own. But for FCOS we made a massive > simplification - the "Live" FCOS *is the same thing as the OS*. Our > `coreos-installer` is just a glorified `dd` wrapper (mostly) and all system > provisioning logic happens in Ignition, which we're constantly testing all of > the time. > (Personally I'm really proud that for example our Live ISO ships with SELinux > enforcing) > > FCOS currently respins both an ostree commit and boot media every release, > and because we use coreos-assembler all the time, those are all strongly > versioned together and consistent. > > Beyond the pungi-vs-bodhi thing of course, to me it is also very fundamental > that our OS build and test process runs natively via podman and Kubernetes > (unprivileged). We're telling people to use containers; building the > operating system shouldn't require you to `yum install` (or even `rpm-ostree` > install stuff directly on a host system. Our current build pipeline is > Jenkins-running-in-OpenShift; we're actively working on removing Jenkins from > the equation in some circumstances and making the whole thing even more > Kubernetes-native. This is not at all true of the Koji/pungi stack. Is that difference really split along tooling lines? I'm not sure it is. You could use pungi to build updated installation media every time there's a push of updates. We just... don't. This seems more split on the OS consumption model to me, rather than the tools to make it. The end user shouldn't care at all about what tools make it. They just want to install their OS and keep it updated and have those updates NOT BREAK their systems or apps. ostree based OS updates have some inherent benefits that a per-package update model lacks and I find it intriguing because you could test a whole OS update stack to at least ensure it's consistent within itself. Whether that happens or not is up to the creators of the OS. You can do the same with bodhi but we... don't. Neither set of tools can really claim to validate the updates won't break third party apps though. (There is the whole pets vs. cattle dynamic too, but I'm not sure that matters much either. The basic requirements should be the same between both: I install or update my pet or cattle and my stuff keeps working unless I want to migrate to something newer). josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 03, 2020 at 01:58:56PM -0500, Colin Walters wrote: > (Personally I'm really proud that for example our Live ISO ships with > SELinux enforcing) This is true of Fedora Workstation and other desktop spin live ISOs as well. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote: > I suppose we could look into this, but it seems kind of complementary to > me: > Server: a install dvd, pxe/netboot > Cloud: a runnable image > Are folks wanting to drop the dvd and netinstall? > Or just market the Cloud image more to server admins that want a ready > to run image? Mostly the latter. I don't even really care if they end up keeping the distinct os-release and etc. > The linux-system-roles is it's own project... so I am not sure what the > working group would do here? Help them? Help them, and help make it feel like a primary feature of Fedora Server. Right now, our marketing materials at https://getfedora.org/en/server/ highlight: * modularity * cockpit * FreeIPA -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote: > > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > the context of how CoreOS is built and released? What set of bits will > we be deciding to ship or not ship, and how will that have been decided > and communicated? Where will we look to find the test results and > criteria on which we would base that decision? There are a whole lot of aspects to this, but one angle to look at this from is that I personally have always thought the way Fedora uses pungi up until releases and everything's about a "compose" and then it switches to a Bodhi wild west where updates are unversioned things that can release at any time...well, it doesn't make much sense. The concept that you have boot media that can reach 6 months old is a very bad anti-pattern because there are often periods of time where the software there has security vulnerabilities. *Particularly* for a desktop system starting up a 6 month old web browser is just actively dangerous. Now I understand there are reasons traditional Fedora does this - among them that Anaconda is a huge thing on its own. But for FCOS we made a massive simplification - the "Live" FCOS *is the same thing as the OS*. Our `coreos-installer` is just a glorified `dd` wrapper (mostly) and all system provisioning logic happens in Ignition, which we're constantly testing all of the time. (Personally I'm really proud that for example our Live ISO ships with SELinux enforcing) FCOS currently respins both an ostree commit and boot media every release, and because we use coreos-assembler all the time, those are all strongly versioned together and consistent. Beyond the pungi-vs-bodhi thing of course, to me it is also very fundamental that our OS build and test process runs natively via podman and Kubernetes (unprivileged). We're telling people to use containers; building the operating system shouldn't require you to `yum install` (or even `rpm-ostree` install stuff directly on a host system. Our current build pipeline is Jenkins-running-in-OpenShift; we're actively working on removing Jenkins from the equation in some circumstances and making the whole thing even more Kubernetes-native. This is not at all true of the Koji/pungi stack. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On Thu, Dec 03, 2020 at 10:29:11AM +0100, Christopher Engelhard wrote: > On 2020-12-03 09:31, David Kaufmann wrote: > > On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote: > > > That would be amazing! In order for it to remain as an edition, we > > > (speaking > > > generally for the Council) like to see regular meetings -- at least > > > monthly. > > > > I'll check the situation there - if there are more people interested in > > a meeting I'll definitely join. There is a set date currently, I can > > make that next week I think and for now I'll just use that one. > > I'd definitely be interested as well. So, the problem here is that without some kind of goal or activities it becomes really hard to meet just to show you exist. There's not too many things for a server working group to do these days. ;( > > > One outstanding thing that could be worked on is the merger of the > > > Fedora > > > Cloud Base image and Fedora Server. We agreed that this should be done > > > several Flocks ago, but no one has had time to actually make it > > > happen. > > > > Until now I thought of both as having a very different target audience, > > I've never looked at Cloud Base, as I almost completely self-host. > > I don't really understand why it should be merged, is there some > > document or chat log for that? > > I have no inside knowledge on this, so these are just my thoughts: > I'd say the cloud & server editions actually do very similar things - I'd > expect that the Fedora Cloud images get most use as a server of some kind. > From a user perspective, if I fired up a Fedora Cloud image on AWS, I'd > expect it to look pretty much like a (maybe pared down?) Fedora Server > Edition. One has anaconda, the other cloud-init (or whatever AWS uses), but > otherwise more or less the same system. Ideally, I would like to be > presented with more or less the same system regardless of whether I'm on > AWS, DO, linode, ... or bare metal. I suppose we could look into this, but it seems kind of complementary to me: Server: a install dvd, pxe/netboot Cloud: a runnable image Are folks wanting to drop the dvd and netinstall? Or just market the Cloud image more to server admins that want a ready to run image? > > > There was also talk of working more closely with Ansible on system > > > roles. > > > I'd love to see that revived too! There is also potential for greater > > > collaboration with CentOS and the CentOS Stream project. I'd love to > > > have a > > > clear, non-competitive answer for each of these projects on when one > > > should > > > use what. > > > > Same as above, I'd like to read up on that. I'm not sure what "system > > roles" relate to, I've found linux-system-roles.github.io and I know > > a big chunk of fedora-infra systems is managed using ansible. > > Again, just my thoughts. This would go very much in the 'discuss what do we > want the edition to be' pile. That said, all editions sort of decide how the > user will by default interact with them. Workstation assumes the user will > manage the system via the DE for obvious reasons, CoreOS assumes that the > user will be managing the system via container tools, Fedora Server assumes > the user will monitor the system via Cockpit, and actually manage it via > poking around in config files. > So one could think about making Ansible the central configuration tool for > Fedora Server, just like Cockpit is its central monitoring tool: > > Workstation = general purpose workstation use, managed & monitored via the > DE > CoreOS = general purpose container/kubernetes use, managed & monitored via > those tools > Server = general purpose non-container server use, managed & monitored via > cockpit & ansible > > Not sure how feasible that is, but I can see the reasoning (full disclosure, > I love ansible, so I'm in no way impartial here). The linux-system-roles is it's own project... so I am not sure what the working group would do here? Help them? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2 Dec 2020 at 21:22, Adam Williamson wrote: > On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote: > > > > > > CoreOS is going to be the same only worse, because it's not even built > > > the same way as the rest of Fedora. It's not built by Pungi, we don't > > > get the same messages published when CoreOS builds happen (we don't get > > > messages published at all, IIRC), the metadata for CoreOS builds is not > > > in productmd[2] form like the metadata for Pungi builds, the whole > > > process is entirely different. > > > > > > > Recently messages were added when streams are updated [0][1]. I believe > > that other messages could be added if needed. > > Right, I forgot about that, thanks. I've got a ticket lying around here > somewhere to make something actually use them...:) > > > > > > So to boil this down into a representative question: when we are doing > > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > > > whether to release "Fedora CoreOS 34"? > > > > > > > > Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing > and > > next, each stream is released every 2 weeks. > > The Go/No-Go is based on reports coming from each stream, next stream is > > promoted to testing and testing promoted to stable. > > If any blockers are found in next or testing the content will not be > > promoted to stable. > > > > I think it is fairly well explained here[2] > > > > > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > > > the context of how CoreOS is built and released? What set of bits will > > > we be deciding to ship or not ship, and how will that have been decided > > > and communicated? Where will we look to find the test results and > > > criteria on which we would base that decision? > > > > > > > > To maintain a fortnightly cadence there is a strong reliance on CI, every > > build is tested and results are inspected during the release process. > > Currently a release is gated on tests running on AWS, GCP and Openstack, > > these tests are running on a centos-ci jenkins instance which I think > > cannot be access without a centos account (I might be wrong), but yeah > > making these tests and results more transparent could be an improvement. > > Right, but - as I think you started to recognize later in your mail - > we're sort of talking at cross-purposes here. You're talking about a > process that has been developed kind of in isolation for building and > releasing a thing which has the name "Fedora CoreOS" but doesn't > actually really integrate much at all with the processes we have for > building and releasing all the other things that make up "Fedora". > Indeed and this was because the current tools and processes were not designed to work with a Fedora releasing every 2 weeks. Being allowed to think outside of the box and doing things differently is IMO a good thing and should be encouraged. > > This is kind of fine as things stand because the thing with the name > "Fedora CoreOS" isn't considered to be a core fundamental part of the > thing with the name "Fedora". But this Change is about making it that. > Doing that causes all sorts of awkward impedance mismatches. Like, > saying "Fedora CoreOS 34 does not exist" is awkward, because we still > have this kind of institutional concept of a "Fedora release" which is > important to what the thing called "Fedora" is and does. To the outside > world, there is a strong impression that the thing called "Fedora" is a > product or set of products with a release number that gets released > every six months. The concept of "Fedora 33 release" or "Fedora 34 > release" is a strong concept with all these sort of institutional > ripples. > And why cannot we make this evolve ? Is it bad to have a Fedora that has streams instead of versions ? Promoting FCOS to an edition is the opportunity to communicate about this and say to the outside, hey we have this new thing in Fedora that has a different model come and check it out. Fedora has the reputation of leading innovation and doing things first, I would like to think that making Fedora CoreOS an edition would match these values. Also having a different model allows us to expand and reach out to other types of users. For years I have heard "I would like to run Fedora on my server, but there is no LTS and I don't want to do a major upgrade every year". Why wouldn't be Fedora CoreOS, a possible answer to that problem ? I believe that we need to be open to doing things differently and welcome different use cases. > > If we want the thing called "Fedora CoreOS" to be a key, fundamental > component of the thing called "Fedora" - which is what making it an > "Edition" is effectively about - we have to deal with those impedance > mismatches. > > So in this case, we could, for instance, make "Fedora CoreOS 34" a > 'thing' by requiring that the CoreOS stable stream gets bumped at the > same time as the rest of the Fedora "release"
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 03, 2020 at 09:31:43AM +0100, David Kaufmann wrote: > Until now I thought of both as having a very different target audience, > I've never looked at Cloud Base, as I almost completely self-host. > I don't really understand why it should be merged, is there some > document or chat log for that? Possibly, but it's not very long so I'll just summarize. The basics are: When we came up with this split at Flock Charleston in 2013, the idea was to focus as you say on different target audiences. We envisioned the cloud image getting more cloud-specific, and Fedora Server getting a bunch of features like Server Roles which people who wanted a lightweight cloud-focused base wouldn't necessarily care for. Over time, it's evolved so Fedora CoreOS fills the new-way-of-doing-things container-focused world niche, but people still wanted the more-traditional Fedora Cloud Base to build on. Meanwhile, people mostly aren't using the Server Roles in their various attempted incarnations, and are just using it as a base system to build their own local solutions. So, we've ended up with two things which are basically used in the same way, with "where it's deployed" being the main differentiator. It makes more sense to merge them together into one thing that can be deployed in different places. Also, both the Cloud SIG and Server SIG have been under-staffed (with the attention on CoreOS and ... not Server, generally). So, rather than having two groups each with one or two struggling members, it seems better to have a shared group with two or four less-struggling members. :) > Same as above, I'd like to read up on that. I'm not sure what "system > roles" relate to, I've found linux-system-roles.github.io and I know > a big chunk of fedora-infra systems is managed using ansible. Here's a pretty good blog post on thoughts from a few years ago: https://sgallagh.wordpress.com/2016/10/13/fedora-server-expanding-throughout-the-galaxy/ And the System Roles project: https://linux-system-roles.github.io/ and docs for System Roles in RHEL, which nominally this should be the upstream for: https://access.redhat.com/articles/3050101 -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
Ben Cotton wrote: > This changes is to promote Fedora CoreOS to Edition status alongside > Workstation, Server and IoT. IMHO, Fedora CoreOS is still an experiment with way too many limitations and drawbacks to warrant Edition status. Don't get me wrong, it is nice to have a place for experiments, and this is an important way to drive innovation, but one needs to distinguish between an experiment and a product, and accept that not all experiments succeed at eventually becoming products, ever. Declaring something an Edition will not magically make it readier for user consumption. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2020-12-02 at 21:25 -0500, Dusty Mabe wrote: > > Ideally we update our stable stream closer to Fedora's actual release date > but I think it's > important to maybe release Fedora CoreOS from the notion that it's tightly > coupled with the > Fedora major release date for a few reasons: I'm pretty sure I covered this in my original mail. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, Dec 3, 2020 at 3:27 AM Dusty Mabe wrote: > There are three update streams for Fedora CoreOS. The "stable" stream is > still > on Fedora 32 but has been receiving bi-weekly updates and should be > switched over > to Fedora 33 soon (probably this week). The `next` and `testing` streams > have been > updated to Fedora 33 and the `next` stream has been on F33 since early > october. My > point here is that if you want Fedora 33 and you are a Fedora CoreOS user > you can > easily adopt a stream that has it. > Since FCOS has automatic updates, perhaps the messaging could be something along the lines "Selected users will begin their automatic upgrade process to F34 in the next few days, and the full rollout to all users is expected to be finished in a couple of weeks. If you want to upgrade early, you can manually switch to the 'testing' branch immediately.". I think it's pretty much expected these days that major large-scale upgrades first hit 1% of the user base, then 10%, then 100% (or similar). Think Android/iOS upgrades, etc. So if the same approach is taken with FCOS, shortly after F34 is GA, I believe this process can be pretty clear to the users, if explained well. And integrate well with their and our expectations at the same time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On 2020-12-03 09:31, David Kaufmann wrote: On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote: That would be amazing! In order for it to remain as an edition, we (speaking generally for the Council) like to see regular meetings -- at least monthly. I'll check the situation there - if there are more people interested in a meeting I'll definitely join. There is a set date currently, I can make that next week I think and for now I'll just use that one. I'd definitely be interested as well. One outstanding thing that could be worked on is the merger of the Fedora Cloud Base image and Fedora Server. We agreed that this should be done several Flocks ago, but no one has had time to actually make it happen. Until now I thought of both as having a very different target audience, I've never looked at Cloud Base, as I almost completely self-host. I don't really understand why it should be merged, is there some document or chat log for that? I have no inside knowledge on this, so these are just my thoughts: I'd say the cloud & server editions actually do very similar things - I'd expect that the Fedora Cloud images get most use as a server of some kind. From a user perspective, if I fired up a Fedora Cloud image on AWS, I'd expect it to look pretty much like a (maybe pared down?) Fedora Server Edition. One has anaconda, the other cloud-init (or whatever AWS uses), but otherwise more or less the same system. Ideally, I would like to be presented with more or less the same system regardless of whether I'm on AWS, DO, linode, ... or bare metal. There was also talk of working more closely with Ansible on system roles. I'd love to see that revived too! There is also potential for greater collaboration with CentOS and the CentOS Stream project. I'd love to have a clear, non-competitive answer for each of these projects on when one should use what. Same as above, I'd like to read up on that. I'm not sure what "system roles" relate to, I've found linux-system-roles.github.io and I know a big chunk of fedora-infra systems is managed using ansible. Again, just my thoughts. This would go very much in the 'discuss what do we want the edition to be' pile. That said, all editions sort of decide how the user will by default interact with them. Workstation assumes the user will manage the system via the DE for obvious reasons, CoreOS assumes that the user will be managing the system via container tools, Fedora Server assumes the user will monitor the system via Cockpit, and actually manage it via poking around in config files. So one could think about making Ansible the central configuration tool for Fedora Server, just like Cockpit is its central monitoring tool: Workstation = general purpose workstation use, managed & monitored via the DE CoreOS = general purpose container/kubernetes use, managed & monitored via those tools Server = general purpose non-container server use, managed & monitored via cockpit & ansible Not sure how feasible that is, but I can see the reasoning (full disclosure, I love ansible, so I'm in no way impartial here). Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote: > That would be amazing! In order for it to remain as an edition, we (speaking > generally for the Council) like to see regular meetings -- at least monthly. I'll check the situation there - if there are more people interested in a meeting I'll definitely join. There is a set date currently, I can make that next week I think and for now I'll just use that one. > There are two open issues in the tracker at > https://pagure.io/fedora-server/issues, and even if it's not ever a flood of > things just making sure they're looked at helps keep things going. It seems to me that both can be closed: - #4: the image target size seems to be fine (not whats in the ticket, but the image also matches those sizes) - #5: this seems to be in the wrong group - it looks like it belongs to pagure.io/cloud-sig > […] > One outstanding thing that could be worked on is the merger of the Fedora > Cloud Base image and Fedora Server. We agreed that this should be done > several Flocks ago, but no one has had time to actually make it happen. Until now I thought of both as having a very different target audience, I've never looked at Cloud Base, as I almost completely self-host. I don't really understand why it should be merged, is there some document or chat log for that? > There was also talk of working more closely with Ansible on system roles. > I'd love to see that revived too! There is also potential for greater > collaboration with CentOS and the CentOS Stream project. I'd love to have a > clear, non-competitive answer for each of these projects on when one should > use what. Same as above, I'd like to read up on that. I'm not sure what "system roles" relate to, I've found linux-system-roles.github.io and I know a big chunk of fedora-infra systems is managed using ansible. All the best, Astra signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On 12/2/20 12:57 PM, Ben Cotton wrote: > On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson > wrote: >> >> So to boil this down into a representative question: when we are doing >> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide >> whether to release "Fedora CoreOS 34"? >> > This question is relevant to my interests. That's fair. I think the answer to this question is that we need to consider the way the Fedora CoreOS update streams/release model can play into this. In short I think we'll all need to evolve a bit. It's just not going to be the exact same as traditional Fedora major releases have been. > > On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson > wrote: >> >> Note that if you go to getfedora.org and click on CoreOS *right now*, >> it offers you a Fedora 32-based CoreOS. This is the kind of thing that >> is kinda fine so long as it's an Emerging Edition. It would *not*, >> IMHO, be fine for an Edition. If we accept CoreOS as an edition and two >> months after Fedora 34 is "released", our "stable" CoreOS is still >> Fedora 33-based, that seems like the sort of thing that would look bad. > > I agree. I understand the reasoning, but I'd really like to see FCOS > align with the rest of the schedule or at least develop a clear and > succinct explanation of why it's delayed so that the public and the > tech press can easily understand. I 100% would like to get to a point where we rebase to the latest Fedora major soon after release. As jlebon mentioned earlier this does mean working harder to get ahead of the curve by adopting a rawhide development stream (not exposed to users) and taking more part in the Changes process. > > On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa wrote: >> >> I would personally rather see Fedora CoreOS pulled *back* into the >> fold more as an Edtion > > From a program management perspective, I've largely closed my eyes and > gone "la la la" when it comes to FCOS, in part because it is so > separate from what we know as Fedora. Making FCOS work more like what > we know as Fedora would certainly be helpful from my perspective, but > at the same time there are technical challenges to that. And maybe > what FCOS does from a distro-building standpoint is more like what we > should move toward. Maybe not. Yes. I think we should consider it with a slightly different perspective than we do other editions, but I'm definitely not asking for a pass. Let's work together to define the future. > > In any case, part of the work to be done here, if the Change is > approved, is for me to figure out how to include FCOS in some of the > program management work. > > I wonder if it would be better to target this for Fedora 35, with some > of the work starting now. Given the work it took to get IoT into the > fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34 > feels pretty optimistic here. I think that's reasonable, but maybe we can meet sooner to try to get some answers to foundational questions answered so that we can be prepared to be in better compliance for the Fedora 35 timeframe. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On 12/2/20 12:33 PM, Adam Williamson wrote: > > Note that if you go to getfedora.org and click on CoreOS *right now*, > it offers you a Fedora 32-based CoreOS. This is the kind of thing that > is kinda fine so long as it's an Emerging Edition. It would *not*, > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two > months after Fedora 34 is "released", our "stable" CoreOS is still > Fedora 33-based, that seems like the sort of thing that would look bad. > There are three update streams for Fedora CoreOS. The "stable" stream is still on Fedora 32 but has been receiving bi-weekly updates and should be switched over to Fedora 33 soon (probably this week). The `next` and `testing` streams have been updated to Fedora 33 and the `next` stream has been on F33 since early october. My point here is that if you want Fedora 33 and you are a Fedora CoreOS user you can easily adopt a stream that has it. Why is our FCOS stable stream still on Fedora 32? Our FCOS instances have automatic updates on by default and we're trying very hard to not break systems on upgrade and require human intervention. There are several changes in Fedora 33, including migrating to systemd-resolved and also systemd changing the default fallback hostname from `localhost` to `fedora` that are causing issues for people and we're trying to consider these things first. Ideally we update our stable stream closer to Fedora's actual release date but I think it's important to maybe release Fedora CoreOS from the notion that it's tightly coupled with the Fedora major release date for a few reasons: - we have people follow update streams and systems update automatically - it's more of a "rolling" release, with incremental feature improvements and major rebases periodically - this is a departure from Atomic Host where you had to manually decide when to do a major rebase - new features get added all the time, mid stream, so it's more of a continuous development model Ultimately it's just a slightly different release/development model (adopted from CoreOS Container Linux) than what Fedora has traditionally used, but I don't think that's any reason to treat it like it's not Fedora. We should embrace it and see the positives along with the negatives of the model. Dusty P.S. For more info on our various update streams see: https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 02, 2020 at 10:59:50PM +0100, David Kaufmann wrote: > Count me in, but honestly I don't see a lot of things that need to be > changed - I'm quite happy with how it behaves. But aside that I'm happy > to help with those issues that come up. That would be amazing! In order for it to remain as an edition, we (speaking generally for the Council) like to see regular meetings -- at least monthly. There are two open issues in the tracker at https://pagure.io/fedora-server/issues, and even if it's not ever a flood of things just making sure they're looked at helps keep things going. That plus status updates on https://docs.fedoraproject.org/en-US/project/dashboard/ regularly. And of course people showing up to help with issues at release time. One outstanding thing that could be worked on is the merger of the Fedora Cloud Base image and Fedora Server. We agreed that this should be done several Flocks ago, but no one has had time to actually make it happen. There was also talk of working more closely with Ansible on system roles. I'd love to see that revived too! There is also potential for greater collaboration with CentOS and the CentOS Stream project. I'd love to have a clear, non-competitive answer for each of these projects on when one should use what. And, of course, there's helping develop marketing materials for Mindshare groups to use to help the Edition grow more users. But none of these latter things are _necessary_. It's really the first thing of just reviving the cadence of meetings and status updates. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
Hi! On Wed, Dec 02, 2020 at 11:11:02AM -0500, Ben Cotton wrote: > One uncomfortable question that this raises: is it time to de-Edition > Fedora Server? Please don't, for me it is the Version I'm currently migrating my Centos 7 boxes to, so having it properly tested and being high on the "if it breaks it needs to be fixed"-list is kinda important for me. > As far as I can tell, the Server Working Group has essentially been > dormant for a while, with sgallagh coming in to fix issues when they > arise. So one alternative to demoting Server would be for someone to > revive that WG. Count me in, but honestly I don't see a lot of things that need to be changed - I'm quite happy with how it behaves. But aside that I'm happy to help with those issues that come up. All the best, Astra signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Release cadence and Editions [was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On Wed, Dec 02, 2020 at 12:15:21PM -0800, Adam Williamson wrote: > with quite a lot of consequences. It has consequences, for instance, > for our most important forms of communication to the wider world: how > do we pivot from this simple story that "Fedora is a (set of) > product(s) that come(s) out every six months, look out for our big > Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO > this other thing that has three streams which release every two weeks > and roll over according to some completely other schedule"? And so on. I think some of this is helped by not thinking of Fedora as the OS itself, just like Red Hat isn't RHEL and RHEL isn't Red Hat. I mean, it doesn't solve any of your problems :) but it's a start towards getting people to think about it differently. I think this reads a lot more simply: Fedora is a project that has a set of deliverables that have traditionally been released every six months. We now have some deliverables that follow a different schedule. We're moving to a model where our main underlying software repository updates on the traditional six-month cadence, our various products will come with their own release announcements. Fedora Workstation, which is our most popular desktop offering, will stay on the familiar April/October release cadence. Silverblue, IoT, and CoreOS are examples of other Fedora operating system flavors that follow a rolling-release model instead. Our KDE Plasma Desktop follows the upstream KDE releases, which happen every four months, using the most-current Fedora software base at that time. [This last statement is obviously not true, but I'd like it to be a possiblity.] On the other hand, our Fedora School OS flavor [also not real] updates only once a year, at the end of May, so that school IT teams can deploy over the summer and not worry about upgrades until the next summer. Obviously there's some hard work to make that into a reality. But that's what I'd like to get to and it's basically what the Council decided we'd like a couple of years ago. (See below.) Right now, most of the press we get is around Fedora Workstation no matter what we do. (I have tried very hard to get press folks to talk about Fedora Server, Atomic, CoreOS, IoT, KDE and Xfce, SoaS, etc., etc., and I'm lucky if I get a line or two in an article.) If we want press around other offerings — desktop, or other use cases — it'll actually be _better_ to split them off so they're not overshadowed. > Good question! getfedora.org uses the concept, but doesn't define it. > So the authoritative source, I guess, is still > https://fedoraproject.org/wiki/Editions , which says "Fedora Editions > are curated sets of packages, guidelines and configuration, and > artifacts built from those pieces, that address a specific, targeted > use-case. The Editions are the primary Fedora outputs that most Fedora > users are encouraged to use and directed towards through the download > site." The latest official definition is in https://docs.fedoraproject.org/en-US/council/policy/guiding-policy/#_what_does_this_mean, which says: "Some solutions are the premier showcases that we call Editions; these are used in the gating tests for our releases." I'm not super-set on that, though, and would be open to some further evolution. For example, "gating tests for our releases" should probably be "for the twice-yearly Fedora rpm repository major-version releases" or something.¹ And, I think some element of this still is the key thing: we shouldn't do the general-repo release if it's not possible for the next release of an Edition to be based on it. This document is where we also said "Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence."² > Rawhide isn't an edition, which I think should be clear from the > definitions above. Rawhide is sort of the primordial soup from which > Editions and all else eventually emerges, I guess. :P I am totally up for renaming it to Fedora Primordial Soup. :) ... 1. I'm also open to having more or fewer things that are Editions, and finding new and better ways to let teams promote their not-labeled-as-edition outputs. 2. Put "release cadence" in bold for the purposes of this message. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote: > > > > CoreOS is going to be the same only worse, because it's not even built > > the same way as the rest of Fedora. It's not built by Pungi, we don't > > get the same messages published when CoreOS builds happen (we don't get > > messages published at all, IIRC), the metadata for CoreOS builds is not > > in productmd[2] form like the metadata for Pungi builds, the whole > > process is entirely different. > > > > Recently messages were added when streams are updated [0][1]. I believe > that other messages could be added if needed. Right, I forgot about that, thanks. I've got a ticket lying around here somewhere to make something actually use them...:) > > > > So to boil this down into a representative question: when we are doing > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > > whether to release "Fedora CoreOS 34"? > > > > > Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and > next, each stream is released every 2 weeks. > The Go/No-Go is based on reports coming from each stream, next stream is > promoted to testing and testing promoted to stable. > If any blockers are found in next or testing the content will not be > promoted to stable. > > I think it is fairly well explained here[2] > > > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > > the context of how CoreOS is built and released? What set of bits will > > we be deciding to ship or not ship, and how will that have been decided > > and communicated? Where will we look to find the test results and > > criteria on which we would base that decision? > > > > > To maintain a fortnightly cadence there is a strong reliance on CI, every > build is tested and results are inspected during the release process. > Currently a release is gated on tests running on AWS, GCP and Openstack, > these tests are running on a centos-ci jenkins instance which I think > cannot be access without a centos account (I might be wrong), but yeah > making these tests and results more transparent could be an improvement. Right, but - as I think you started to recognize later in your mail - we're sort of talking at cross-purposes here. You're talking about a process that has been developed kind of in isolation for building and releasing a thing which has the name "Fedora CoreOS" but doesn't actually really integrate much at all with the processes we have for building and releasing all the other things that make up "Fedora". This is kind of fine as things stand because the thing with the name "Fedora CoreOS" isn't considered to be a core fundamental part of the thing with the name "Fedora". But this Change is about making it that. Doing that causes all sorts of awkward impedance mismatches. Like, saying "Fedora CoreOS 34 does not exist" is awkward, because we still have this kind of institutional concept of a "Fedora release" which is important to what the thing called "Fedora" is and does. To the outside world, there is a strong impression that the thing called "Fedora" is a product or set of products with a release number that gets released every six months. The concept of "Fedora 33 release" or "Fedora 34 release" is a strong concept with all these sort of institutional ripples. If we want the thing called "Fedora CoreOS" to be a key, fundamental component of the thing called "Fedora" - which is what making it an "Edition" is effectively about - we have to deal with those impedance mismatches. So in this case, we could, for instance, make "Fedora CoreOS 34" a 'thing' by requiring that the CoreOS stable stream gets bumped at the same time as the rest of the Fedora "release" happening. That gives us a nice simple story that fits into our existing way of doing things. This is more or less what we did with IoT: as things stand, the situation with IoT is "OK, it's built from a separate compose stream, but we still expect it to tie into the release cycle. We expect there to be a release candidate based on the same bits as the mainline release, with the same release number, that we sign off and release at the same time." Of course, that's also the drawback. If we don't want to do that, we have to resolve the problem some other way, which is quite a fundamental thing, if you think about it. My point here is that to do that properly, we have to reconsider the strong idea that "Fedora is a product that comes out every six months", which is a big job that comes with quite a lot of consequences. It has consequences, for instance, for our most important forms of communication to the wider world: how do we pivot from this simple story that "Fedora is a (set of) product(s) that come(s) out every six months, look out for our big Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO this other thing that has three streams which release every two weeks and roll over according to some completely other schedule"? And so on. I'm not
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa wrote: > This is a fair point. I've personally been very annoyed about how > little Fedora CoreOS integrates with the rest of the Fedora Project. > One very broken consequence of Fedora CoreOS working this way is that > they basically *don't* participate in Changes discussions and just do > things differently without warning or documentation. This has led to > problems when Fedora CoreOS differs from the rest of Fedora in core, > fundamental ways. This has even happened unintentionally, where Fedora > CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using > the wrong variant of iptables: > https://github.com/coreos/fedora-coreos-tracker/issues/676 We do look over every Fedora Changes that come through and evaluate how we need to adapt FCOS for them. I agree we could do a better job at providing more timely feedback to change owners and the community (thinking about the recent rpmdb backend change for example). Part of it I think is that we do not yet have a rawhide stream which would expose us to all these changes earlier (it's on the radar though!). But to be clear, the intent is always to match Fedora whenever possible. Due to our update model, we have to be extremely careful about these changes, and sometimes that means that FCOS lags behind a bit in getting them. The iptables example was an unfortunate slip up; ordinarily this would've been part of the f32 rebase just like the rest of Fedora. > Additionally, to the point about their tooling: there's been a bunch > of effort to plug OSBuild based image builds into our normal > infrastructure, and given that even Fedora IoT Edition can > successfully be produced through that pipeline, I would think that we > should have Fedora CoreOS transition to it. There's a lot more effort > going around OSBuild within the project as a whole, and it's much more > likely that we'll be able to incorporate that into the general > infrastructure in a way that makes it traceable and actionable within > and outside the project. I agree build tooling is an important part of the picture. Both teams of coreos-assembler and osbuild are aware of the overlap that exists and we do plan to discuss this further. Though this is not something we are likely to tackle in any serious way anytime soon. So for the purposes of this discussion, I hope we can put this aside. We do run our builds in CentOS CI, but we're open to integrating with Fedora processes in any way necessary. For example, we recently added informational fedmsgs when builds and releases happen as Clement linked to above. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2 Dec 2020 at 19:07, Ben Cotton wrote: > On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson > wrote: > > > > So to boil this down into a representative question: when we are doing > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > > whether to release "Fedora CoreOS 34"? > > > This question is relevant to my interests. > > On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson > wrote: > > > > Note that if you go to getfedora.org and click on CoreOS *right now*, > > it offers you a Fedora 32-based CoreOS. This is the kind of thing that > > is kinda fine so long as it's an Emerging Edition. It would *not*, > > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two > > months after Fedora 34 is "released", our "stable" CoreOS is still > > Fedora 33-based, that seems like the sort of thing that would look bad. > > I agree. I understand the reasoning, but I'd really like to see FCOS > align with the rest of the schedule or at least develop a clear and > succinct explanation of why it's delayed so that the public and the > tech press can easily understand. > It is hard for something that releases every 2 weeks to align with the rest of the schedule, we have the same struggle with the container images. It feels odd to have to wait 6 months to introduce changes when you release a new version every couple weeks. > > On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa wrote: > > > > I would personally rather see Fedora CoreOS pulled *back* into the > > fold more as an Edtion > > From a program management perspective, I've largely closed my eyes and > gone "la la la" when it comes to FCOS, in part because it is so > separate from what we know as Fedora. Making FCOS work more like what > we know as Fedora would certainly be helpful from my perspective, but > at the same time there are technical challenges to that. And maybe > what FCOS does from a distro-building standpoint is more like what we > should move toward. Maybe not. > > In any case, part of the work to be done here, if the Change is > approved, is for me to figure out how to include FCOS in some of the > program management work. > > I wonder if it would be better to target this for Fedora 35, with some > of the work starting now. Given the work it took to get IoT into the > fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34 > feels pretty optimistic here. > I am open to moving this to F3X but I currently don't have a clear idea of what is required to be an Edition. If I could get a list of things that needs to be done, that would help consider if this is doable or not. > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2 Dec 2020 at 18:27, Adam Williamson wrote: > On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote: > > > > == How To Test == > > See QA test cases : > https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases > > > > We also have regular tests days, for example > > https://fedoramagazine.org/fedora-coreos-test-day/ > > So...yeah, that's not really enough to call something a Fedora Edition > :) > > I think this has a lot of the issues we had with IoT, but turned up to > 11. > > We have an entire process for releasing a thing called "Fedora" which > is based around the idea that all the bits that make up a "Fedora > release" get built, tested, and signed off together. > > IoT stretched this process a bit, because it's not actually built as > part of the same composes as all the other "Fedora" bits. So we had to > implement an entire parallel validation process just for IoT composes. > But at least it's built *the same way* as Fedora, so we could more or > less just split existing things into two paths and use them, which is > what we did. We now have both mainline and IoT composes and validation > events. Even there, the process wasn't perfect for Fedora 33; if you > look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed > to be where we go over the status of the bits-to-be-released in great > detail and decide whether to sign them off, there is precisely one line > about IoT: > > 17:58:36 IoT is also covered - > https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install > > ...no-one else said a word about it. So yeah, we clearly don't have > this whole "releasing from multiple streams" entirely down yet. > > CoreOS is going to be the same only worse, because it's not even built > the same way as the rest of Fedora. It's not built by Pungi, we don't > get the same messages published when CoreOS builds happen (we don't get > messages published at all, IIRC), the metadata for CoreOS builds is not > in productmd[2] form like the metadata for Pungi builds, the whole > process is entirely different. > Recently messages were added when streams are updated [0][1]. I believe that other messages could be added if needed. > > So to boil this down into a representative question: when we are doing > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > whether to release "Fedora CoreOS 34"? > > Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and next, each stream is released every 2 weeks. The Go/No-Go is based on reports coming from each stream, next stream is promoted to testing and testing promoted to stable. If any blockers are found in next or testing the content will not be promoted to stable. I think it is fairly well explained here[2] > > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > the context of how CoreOS is built and released? What set of bits will > we be deciding to ship or not ship, and how will that have been decided > and communicated? Where will we look to find the test results and > criteria on which we would base that decision? > > To maintain a fortnightly cadence there is a strong reliance on CI, every build is tested and results are inspected during the release process. Currently a release is gated on tests running on AWS, GCP and Openstack, these tests are running on a centos-ci jenkins instance which I think cannot be access without a centos account (I might be wrong), but yeah making these tests and results more transparent could be an improvement. > > Are any of these silly questions, which would indicate that our release > process is based on assumptions which need to be fundamentally re- > examined as part of this Change? > So what defines an Edition ? I think if we don't want to accept a different philosophy about release schedule and release engineering we can just close that Change proposal. How do you consider Rawhide for example ? > > All of this is stuff we could kind of handwave so long as CoreOS wasn't > an official Edition; we could *more or less* leave the CoreOS team to > decide what a CoreOS release looked like and when it would happen and > when it was good enough to ship, and so on. > So this change comes down to Can we have a Fedora Edition that has a different workflow ? > But if we're going to call it an Edition, which is one of the primary > things that defines what Fedora *is*, I don't think we can do that any > more. We need more groups to think about and decide on the answers to > questions like the above. > [0] - https://github.com/coreos/fedora-coreos-tracker/issues/225 [1] - https://apps.fedoraproject.org/datagrepper/id?id=2020-81657c3b-9703-431a-8c3c-0b409743fac4_raw=true=extra-large [2] - https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams > [1]: > https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html > [2]:
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 5:58 PM Ben Cotton wrote: > > On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson > wrote: > > > > So to boil this down into a representative question: when we are doing > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > > whether to release "Fedora CoreOS 34"? > > > This question is relevant to my interests. > > On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson > wrote: > > > > Note that if you go to getfedora.org and click on CoreOS *right now*, > > it offers you a Fedora 32-based CoreOS. This is the kind of thing that > > is kinda fine so long as it's an Emerging Edition. It would *not*, > > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two > > months after Fedora 34 is "released", our "stable" CoreOS is still > > Fedora 33-based, that seems like the sort of thing that would look bad. > > I agree. I understand the reasoning, but I'd really like to see FCOS > align with the rest of the schedule or at least develop a clear and > succinct explanation of why it's delayed so that the public and the > tech press can easily understand. > > On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa wrote: > > > > I would personally rather see Fedora CoreOS pulled *back* into the > > fold more as an Edtion > > From a program management perspective, I've largely closed my eyes and > gone "la la la" when it comes to FCOS, in part because it is so > separate from what we know as Fedora. Making FCOS work more like what > we know as Fedora would certainly be helpful from my perspective, but > at the same time there are technical challenges to that. And maybe > what FCOS does from a distro-building standpoint is more like what we > should move toward. Maybe not. > > In any case, part of the work to be done here, if the Change is > approved, is for me to figure out how to include FCOS in some of the > program management work. > > I wonder if it would be better to target this for Fedora 35, with some > of the work starting now. Given the work it took to get IoT into the > fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34 > feels pretty optimistic here. From memory we started in IoT Edition process in earnest in F-32, part of the delay here was because there had never really been the process properly defined for promotion, but it took some time and engagement across a number of areas of the project which I feel were useful for the IoT Edition, overall starting the discussion for what's required and expected is useful for the Edition themselves to improve and work in the right direction IMO from experience. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 12:58 PM Ben Cotton wrote: > > On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson > wrote: > > > > So to boil this down into a representative question: when we are doing > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > > whether to release "Fedora CoreOS 34"? > > > This question is relevant to my interests. > > On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson > wrote: > > > > Note that if you go to getfedora.org and click on CoreOS *right now*, > > it offers you a Fedora 32-based CoreOS. This is the kind of thing that > > is kinda fine so long as it's an Emerging Edition. It would *not*, > > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two > > months after Fedora 34 is "released", our "stable" CoreOS is still > > Fedora 33-based, that seems like the sort of thing that would look bad. > > I agree. I understand the reasoning, but I'd really like to see FCOS > align with the rest of the schedule or at least develop a clear and > succinct explanation of why it's delayed so that the public and the > tech press can easily understand. > I would probably suggest that they *must* make it so they can rebase and release to a new stable release when the rest of the platform does. If they want to make releases faster (a la Fedora Cloud), that's fine. But being slower is not acceptable, IMHO. > On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa wrote: > > > > I would personally rather see Fedora CoreOS pulled *back* into the > > fold more as an Edtion > > From a program management perspective, I've largely closed my eyes and > gone "la la la" when it comes to FCOS, in part because it is so > separate from what we know as Fedora. Making FCOS work more like what > we know as Fedora would certainly be helpful from my perspective, but > at the same time there are technical challenges to that. And maybe > what FCOS does from a distro-building standpoint is more like what we > should move toward. Maybe not. > > In any case, part of the work to be done here, if the Change is > approved, is for me to figure out how to include FCOS in some of the > program management work. > > I wonder if it would be better to target this for Fedora 35, with some > of the work starting now. Given the work it took to get IoT into the > fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34 > feels pretty optimistic here. I suspect that you're right and this should be retargeted for Fedora 35. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson wrote: > > So to boil this down into a representative question: when we are doing > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > whether to release "Fedora CoreOS 34"? > This question is relevant to my interests. On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson wrote: > > Note that if you go to getfedora.org and click on CoreOS *right now*, > it offers you a Fedora 32-based CoreOS. This is the kind of thing that > is kinda fine so long as it's an Emerging Edition. It would *not*, > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two > months after Fedora 34 is "released", our "stable" CoreOS is still > Fedora 33-based, that seems like the sort of thing that would look bad. I agree. I understand the reasoning, but I'd really like to see FCOS align with the rest of the schedule or at least develop a clear and succinct explanation of why it's delayed so that the public and the tech press can easily understand. On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa wrote: > > I would personally rather see Fedora CoreOS pulled *back* into the > fold more as an Edtion From a program management perspective, I've largely closed my eyes and gone "la la la" when it comes to FCOS, in part because it is so separate from what we know as Fedora. Making FCOS work more like what we know as Fedora would certainly be helpful from my perspective, but at the same time there are technical challenges to that. And maybe what FCOS does from a distro-building standpoint is more like what we should move toward. Maybe not. In any case, part of the work to be done here, if the Change is approved, is for me to figure out how to include FCOS in some of the program management work. I wonder if it would be better to target this for Fedora 35, with some of the work starting now. Given the work it took to get IoT into the fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34 feels pretty optimistic here. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote: > There were a number of people interested in helping with reviving the > Server WG, myself included. But we don't know how to have that move > forward. We've never really had a situation like this before... > I'd start with staging a takeover of https://fedoraproject.org/wiki/Server It looks like there are no meeting logs in the last two years, so I don't think you'll get much pushback. I talked to sgallagh before posing this question, so I don't expect you'll get any pushback. If anything, you'll probably make people happy. :-) On Wed, Dec 2, 2020 at 12:30 PM Adam Williamson wrote: > > I'm not sure it's really warranted, to be honest. A counterpoint is > that you can consider Server to be sort of dormant *because it works*. Is "it still works" sufficient to keep a deliverable at the forefront? Obviously we want what we ship to work, whether it's an Edition or bex's Llama Herder Lab. But what is Server doing to move the state of the art forward? Server is a slightly different case in that generally you don't want servers to be too adventurous, but if it's in statis, should it be a flagship? Like I said above, the Server WG appears to be in zombie state for at least the last two years. Is Fedora Server doing what it should be doing now, or is it doing what it should have done two years ago? > Of course, we can keep publishing Server images and providing those > capabilities without calling it an Edition, but...I'm not sure it just > being sort of quiet and undramatic necessarily merits that, especially > if we don't have clear replacements for its capabilities yet. I'm certainly not advocating we drop Server entirely. But we should evaluate its place in Fedora, particularly if there's no one providing active care and feeding. I'd much rather see the Server WG come back to life and keep it as an Edition. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2020-12-02 at 09:56 -0500, Neal Gompa wrote: > > Meh, sure I guess? This is a paperwork change. It's been considered an > Edition in practice since it replaced Fedora Atomic, which *was* a > full Edition in its own right. I would dispute that. To me the most obvious factor here is: what do you see when you go to download Fedora? What you see is this: https://getfedora.org/ which is very clear that the Editions - the primary Fedora Things - are Workstation, Server and IoT. CoreOS and Silverblue are clearly labeled "Emerging Fedora Editions", which clearly communicates to people "these are things we consider important but aren't ready to make the Main Things" yet - they are, as the subhead says, "the future of Fedora". This is admirably clear messaging, I think, and it means that people will give us a pass on all the sorts of awkward questions I asked in my other mail. If CoreOS moves up a few hundred pixels, we will *not* get a pass on those questions. If we release a bad CoreOS, it will reflect badly on Fedora. If we do a "Fedora release" and just basically forget to include CoreOS in the messaging for that release at all, that will look bad. Note that if you go to getfedora.org and click on CoreOS *right now*, it offers you a Fedora 32-based CoreOS. This is the kind of thing that is kinda fine so long as it's an Emerging Edition. It would *not*, IMHO, be fine for an Edition. If we accept CoreOS as an edition and two months after Fedora 34 is "released", our "stable" CoreOS is still Fedora 33-based, that seems like the sort of thing that would look bad. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 12:19 PM Adam Williamson wrote: > > On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote: > > > > == How To Test == > > See QA test cases : > > https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases > > > > We also have regular tests days, for example > > https://fedoramagazine.org/fedora-coreos-test-day/ > > So...yeah, that's not really enough to call something a Fedora Edition > :) > > I think this has a lot of the issues we had with IoT, but turned up to > 11. > > We have an entire process for releasing a thing called "Fedora" which > is based around the idea that all the bits that make up a "Fedora > release" get built, tested, and signed off together. > > IoT stretched this process a bit, because it's not actually built as > part of the same composes as all the other "Fedora" bits. So we had to > implement an entire parallel validation process just for IoT composes. > But at least it's built *the same way* as Fedora, so we could more or > less just split existing things into two paths and use them, which is > what we did. We now have both mainline and IoT composes and validation > events. Even there, the process wasn't perfect for Fedora 33; if you > look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed > to be where we go over the status of the bits-to-be-released in great > detail and decide whether to sign them off, there is precisely one line > about IoT: > > 17:58:36 IoT is also covered - > https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install > > ...no-one else said a word about it. So yeah, we clearly don't have > this whole "releasing from multiple streams" entirely down yet. > > CoreOS is going to be the same only worse, because it's not even built > the same way as the rest of Fedora. It's not built by Pungi, we don't > get the same messages published when CoreOS builds happen (we don't get > messages published at all, IIRC), the metadata for CoreOS builds is not > in productmd[2] form like the metadata for Pungi builds, the whole > process is entirely different. > > So to boil this down into a representative question: when we are doing > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > whether to release "Fedora CoreOS 34"? > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > the context of how CoreOS is built and released? What set of bits will > we be deciding to ship or not ship, and how will that have been decided > and communicated? Where will we look to find the test results and > criteria on which we would base that decision? > > Are any of these silly questions, which would indicate that our release > process is based on assumptions which need to be fundamentally re- > examined as part of this Change? > > All of this is stuff we could kind of handwave so long as CoreOS wasn't > an official Edition; we could *more or less* leave the CoreOS team to > decide what a CoreOS release looked like and when it would happen and > when it was good enough to ship, and so on. > > But if we're going to call it an Edition, which is one of the primary > things that defines what Fedora *is*, I don't think we can do that any > more. We need more groups to think about and decide on the answers to > questions like the above. > > [1]: > https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html > [2]: https://github.com/release-engineering/productmd This is a fair point. I've personally been very annoyed about how little Fedora CoreOS integrates with the rest of the Fedora Project. One very broken consequence of Fedora CoreOS working this way is that they basically *don't* participate in Changes discussions and just do things differently without warning or documentation. This has led to problems when Fedora CoreOS differs from the rest of Fedora in core, fundamental ways. This has even happened unintentionally, where Fedora CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using the wrong variant of iptables: https://github.com/coreos/fedora-coreos-tracker/issues/676 Additionally, to the point about their tooling: there's been a bunch of effort to plug OSBuild based image builds into our normal infrastructure, and given that even Fedora IoT Edition can successfully be produced through that pipeline, I would think that we should have Fedora CoreOS transition to it. There's a lot more effort going around OSBuild within the project as a whole, and it's much more likely that we'll be able to incorporate that into the general infrastructure in a way that makes it traceable and actionable within and outside the project. I would personally rather see Fedora CoreOS pulled *back* into the fold more as an Edtion. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote: > On Wed, Dec 2, 2020 at 11:11 AM Ben Cotton wrote: > > > > One uncomfortable question that this raises: is it time to de-Edition > > Fedora Server? We'd still produce it, but it would no longer be > > considered an Edition (and thus potentially not block releases, etc, > > the exact implications would have to be worked out) > > > > As far as I can tell, the Server Working Group has essentially been > > dormant for a while, with sgallagh coming in to fix issues when they > > arise. So one alternative to demoting Server would be for someone to > > revive that WG. > > > > Fedora CoreOS is not an exact replacement for Fedora Server, of > > course, but this does present what feels like a natural opportunity to > > ask this question. > > > > There were a number of people interested in helping with reviving the > Server WG, myself included. But we don't know how to have that move > forward. We've never really had a situation like this before... I'm not sure it's really warranted, to be honest. A counterpoint is that you can consider Server to be sort of dormant *because it works*. We have a defined set of capabilities for Fedora Server, testing of them is almost entirely automated, and our releases keep providing those capabilities reliably. We have a couple of representative boring- server-things that Server is required to be able to do well: being a database server, and being a FreeIPA server. We have decent automated tests for those, and when they break, people jump on them and fix them. All our Fedora Server releases have met them pretty well. People run it and are happy. CoreOS can be a database server too, of course. I could set things up to run those tests for CoreOS builds, I guess. I'm not sure it can be a FreeIPA server, or if anyone's even tried. Of course, we can keep publishing Server images and providing those capabilities without calling it an Edition, but...I'm not sure it just being sort of quiet and undramatic necessarily merits that, especially if we don't have clear replacements for its capabilities yet. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote: > > == How To Test == > See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases > > We also have regular tests days, for example > https://fedoramagazine.org/fedora-coreos-test-day/ So...yeah, that's not really enough to call something a Fedora Edition :) I think this has a lot of the issues we had with IoT, but turned up to 11. We have an entire process for releasing a thing called "Fedora" which is based around the idea that all the bits that make up a "Fedora release" get built, tested, and signed off together. IoT stretched this process a bit, because it's not actually built as part of the same composes as all the other "Fedora" bits. So we had to implement an entire parallel validation process just for IoT composes. But at least it's built *the same way* as Fedora, so we could more or less just split existing things into two paths and use them, which is what we did. We now have both mainline and IoT composes and validation events. Even there, the process wasn't perfect for Fedora 33; if you look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed to be where we go over the status of the bits-to-be-released in great detail and decide whether to sign them off, there is precisely one line about IoT: 17:58:36 IoT is also covered - https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install ...no-one else said a word about it. So yeah, we clearly don't have this whole "releasing from multiple streams" entirely down yet. CoreOS is going to be the same only worse, because it's not even built the same way as the rest of Fedora. It's not built by Pungi, we don't get the same messages published when CoreOS builds happen (we don't get messages published at all, IIRC), the metadata for CoreOS builds is not in productmd[2] form like the metadata for Pungi builds, the whole process is entirely different. So to boil this down into a representative question: when we are doing the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide whether to release "Fedora CoreOS 34"? What does the question "is Fedora CoreOS 34 ready to go" even mean, in the context of how CoreOS is built and released? What set of bits will we be deciding to ship or not ship, and how will that have been decided and communicated? Where will we look to find the test results and criteria on which we would base that decision? Are any of these silly questions, which would indicate that our release process is based on assumptions which need to be fundamentally re- examined as part of this Change? All of this is stuff we could kind of handwave so long as CoreOS wasn't an official Edition; we could *more or less* leave the CoreOS team to decide what a CoreOS release looked like and when it would happen and when it was good enough to ship, and so on. But if we're going to call it an Edition, which is one of the primary things that defines what Fedora *is*, I don't think we can do that any more. We need more groups to think about and decide on the answers to questions like the above. [1]: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html [2]: https://github.com/release-engineering/productmd -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 11:11 AM Ben Cotton wrote: > > One uncomfortable question that this raises: is it time to de-Edition > Fedora Server? We'd still produce it, but it would no longer be > considered an Edition (and thus potentially not block releases, etc, > the exact implications would have to be worked out) > > As far as I can tell, the Server Working Group has essentially been > dormant for a while, with sgallagh coming in to fix issues when they > arise. So one alternative to demoting Server would be for someone to > revive that WG. > > Fedora CoreOS is not an exact replacement for Fedora Server, of > course, but this does present what feels like a natural opportunity to > ask this question. > There were a number of people interested in helping with reviving the Server WG, myself included. But we don't know how to have that move forward. We've never really had a situation like this before... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
One uncomfortable question that this raises: is it time to de-Edition Fedora Server? We'd still produce it, but it would no longer be considered an Edition (and thus potentially not block releases, etc, the exact implications would have to be worked out) As far as I can tell, the Server Working Group has essentially been dormant for a while, with sgallagh coming in to fix issues when they arise. So one alternative to demoting Server would be for someone to revive that WG. Fedora CoreOS is not an exact replacement for Fedora Server, of course, but this does present what feels like a natural opportunity to ask this question. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 9:23 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/FedoraCoreOS > > == Summary == > > This changes is to promote Fedora CoreOS to Edition status alongside > Workstation, Server and IoT. > > == Owners == > > * Name: [[User:cverna|Clement Verna]] > * Email: cve...@fedoraproject.org > * Products: Fedora CoreOS > * Responsible WGs: Fedora CoreOS Group > > > == Detailed Description == > > This changes is to promote Fedora CoreOS to Edition status alongside > Workstation, Server and IoT. > > [https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites > Prerequisites] are tracked bellow : > > * Edition has a team with regular public meeting : > [https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting > happening on #fedora-meeting-1] > > * Trademark approval from the Fedora Council : > [https://pagure.io/Fedora-Council/tickets/issue/340 council ticket] > > * Product requirements document (PRD) : > https://fedoraproject.org/wiki/CoreOS/PRD > > * Technical specification : > https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md > > == Feedback == > > == Benefit to Fedora == > > Make Fedora CoreOS an official edition, will help spread adoption and > position Fedora as credible solution for running container workflow. > > == Scope == > * Proposal owners: see change owners > > * Other developers: N/A > > * Release engineering: Fedora CoreOS is already being composed and released. > > * Policies and guidelines: N/A > > * Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340 > > == Upgrade/compatibility impact == > N/A > > == How To Test == > See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases > > We also have regular tests days, for example > https://fedoramagazine.org/fedora-coreos-test-day/ > > == User Experience == > > Pros > > Enhancement opportunities > > == Dependencies == > > == Contingency Plan == > Contingency mechanism: (What to do? Who will do it?) Delay promotion until F35 > > Contingency deadline: F34 Final release date > > Blocks release? No > > == Documentation == > https://docs.fedoraproject.org/en-US/fedora-coreos/ > > == Release Notes == Meh, sure I guess? This is a paperwork change. It's been considered an Edition in practice since it replaced Fedora Atomic, which *was* a full Edition in its own right. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
https://fedoraproject.org/wiki/Changes/FedoraCoreOS == Summary == This changes is to promote Fedora CoreOS to Edition status alongside Workstation, Server and IoT. == Owners == * Name: [[User:cverna|Clement Verna]] * Email: cve...@fedoraproject.org * Products: Fedora CoreOS * Responsible WGs: Fedora CoreOS Group == Detailed Description == This changes is to promote Fedora CoreOS to Edition status alongside Workstation, Server and IoT. [https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites Prerequisites] are tracked bellow : * Edition has a team with regular public meeting : [https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting happening on #fedora-meeting-1] * Trademark approval from the Fedora Council : [https://pagure.io/Fedora-Council/tickets/issue/340 council ticket] * Product requirements document (PRD) : https://fedoraproject.org/wiki/CoreOS/PRD * Technical specification : https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md == Feedback == == Benefit to Fedora == Make Fedora CoreOS an official edition, will help spread adoption and position Fedora as credible solution for running container workflow. == Scope == * Proposal owners: see change owners * Other developers: N/A * Release engineering: Fedora CoreOS is already being composed and released. * Policies and guidelines: N/A * Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340 == Upgrade/compatibility impact == N/A == How To Test == See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases We also have regular tests days, for example https://fedoramagazine.org/fedora-coreos-test-day/ == User Experience == Pros Enhancement opportunities == Dependencies == == Contingency Plan == Contingency mechanism: (What to do? Who will do it?) Delay promotion until F35 Contingency deadline: F34 Final release date Blocks release? No == Documentation == https://docs.fedoraproject.org/en-US/fedora-coreos/ == Release Notes == -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
https://fedoraproject.org/wiki/Changes/FedoraCoreOS == Summary == This changes is to promote Fedora CoreOS to Edition status alongside Workstation, Server and IoT. == Owners == * Name: [[User:cverna|Clement Verna]] * Email: cve...@fedoraproject.org * Products: Fedora CoreOS * Responsible WGs: Fedora CoreOS Group == Detailed Description == This changes is to promote Fedora CoreOS to Edition status alongside Workstation, Server and IoT. [https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites Prerequisites] are tracked bellow : * Edition has a team with regular public meeting : [https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting happening on #fedora-meeting-1] * Trademark approval from the Fedora Council : [https://pagure.io/Fedora-Council/tickets/issue/340 council ticket] * Product requirements document (PRD) : https://fedoraproject.org/wiki/CoreOS/PRD * Technical specification : https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md == Feedback == == Benefit to Fedora == Make Fedora CoreOS an official edition, will help spread adoption and position Fedora as credible solution for running container workflow. == Scope == * Proposal owners: see change owners * Other developers: N/A * Release engineering: Fedora CoreOS is already being composed and released. * Policies and guidelines: N/A * Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340 == Upgrade/compatibility impact == N/A == How To Test == See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases We also have regular tests days, for example https://fedoramagazine.org/fedora-coreos-test-day/ == User Experience == Pros Enhancement opportunities == Dependencies == == Contingency Plan == Contingency mechanism: (What to do? Who will do it?) Delay promotion until F35 Contingency deadline: F34 Final release date Blocks release? No == Documentation == https://docs.fedoraproject.org/en-US/fedora-coreos/ == Release Notes == -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
