Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 1:02 PM David Cantrell wrote: > > On 8/27/19 2:00 PM, Chris Murphy wrote: > > The Fedora working group's technical specification states Btrfs is to > > be the default. Yet the working group has said it's uncomfortable > > taking action on this decision expressly because the Federal kernel > > team's official recommendation is to not recommend Btrfs. And I agree. > > I trust the Fedora kernel team as they've clearly stated limited > > resources and interest in Btrfs, the expectations and parameters for > > properly supporting Btrfs either as bug blocker worthy, and as a > > default file system from a user advocacy point of view. > > OK, so 8 years has gone by and the landscape around btrfs looks > different in Fedora. Given the kernel team's position, is it worth > still having the FESCo decision and kernel team's recommendation at odds? They aren't at odds. 8 years ago FESCo decision on Btrfs 5 years ago Workstation working group decision on Btrfs (their requirements and specs docs were signed off by FESCo) 3 years ago kernel team said while they don't recommend it, they acknowledged it was ultimately up to the working group to decide, and noted they were sick of having this conversation every release The Workstation working group has, correctly in my view, put their own decision in abeyance, as a result of the kernel team's official recommendation. How does the Btrfs landscape in Fedora look different to you in three years? The way the landscape looks different to me: One, the possibility of getting a kernel engineer who works on Btrfs to join the Fedora kernel team, so that the team has the capacity to support and recommend (at least as a team, not that any individual needs to give up one tiny bit of their Btrfs scepticism) is an important development. Two, that in the interim, Red Hat is where the landscape has really changed has occurred with respect to Btrfs, and I see indications of this bias being injected back into Fedora: suggesting that a Red Hat shift away from Btrfs somehow is actually a Fedora shift away from Btrfs, suggesting a do over vote in the Workstation working group, or even an undo vote by FESCo to set aside the Workstation working group vote. And to what end? All that's needed is for the Anaconda team to provided the same courtesy of clear expectations and parameters, as the kernel team has done. > > >> If it's a best effort thing, then that makes it easier for > >> projects and contributors. Going back to Adam's original list, I would > >> suggest a FESCo decision like this should require explicit opt-in by the > >> user to enable btrfs functionality in the application in question. For > >> example, in the installer that could be enabled via a boot parameter (we > >> did this initially when btrfs functionality was first enabled in anaconda). > > > > That can only be considered to be a remarkable regression, not just in > > the context of Fedora, but in the context of the top 10 linux > > distributions all of which have visible Btrfs support in their GUI > > installers. Fedora's installer being the first to make Btrfs invisible > > by default would be a remarkable first indeed. > > I'm merely offering an example scenario. > > This does illustrate a problem with expectations among users. It's > visible now, but not a priority, which leads to frustration. Just like today's kernel team, Anaconda today are not obligated to make it a priority. But qualifying what "not a priority" actually means is necessary. The question is what are the preconditions for others who will make it a priority? And whether Anaconda is going to slow walk every PR that tries to improve Btrfs support? What about simplifying the Btrfs support in Anaconda to make it easier to maintain with priority parity with other file systems? Gut all the multiple device stuff, perhaps? Btrfs can easily do quite a lot of adjustments post-install, it's one of it's most central features. Few options are mkfs only. > >> I'm not advocating one way or another for btrfs. But it seems we as a > >> project need a larger decision and policy around btrfs in general so we > >> can set expectations for users and developers. > > > > That decision and policy has already been made. Do you want it reverted? > > I guess I meant to say "FESCo needs to revisit this decision for a > potential change". I can't parse this. Which decision, and what potential change? -- Chris Murphy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
References: FESCo, make Btrfs the default https://meetbot.fedoraproject.org/fedora-meeting/2011-06-08/fesco.2011-06-08-17.30.log.html Workstation working group's technical specification, make btrfs default https://fedoraproject.org/wiki/Workstation/Technical_Specification A point of reference that when LVM thinp was made release blocking, it was stated that usability issues are to be treated as bugs to be worked out https://meetbot.fedoraproject.org/fedora-meeting/2013-07-24/fesco.2013-07-24-18.00.log.html File system choice is up to the working group https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/CXW6IYIHETPS5U7IB2P6373FJDU2UAMB/ --- Chris Murphy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 12:00 PM Chris Murphy wrote: > The Fedora working group's technical specification states Btrfs is to > be the default. Yet the working group has said it's uncomfortable > taking action on this decision expressly because the Federal kernel > team's official recommendation is to not recommend Btrfs. And I agree. Points of clarity: - it is the Workstation working group's technical spec that says this (the Server working group decided on XFS) - I agree with Workstation working group's reticence to actually deploy Btrfs as the default file system, while the Fedora kernel team recommends against Btrfs as the default. And I would like someone on the Fedora kernel team who will recommend and support it. -- Chris Murphy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 11:25 AM David Cantrell wrote: > > The installer team rejecting btrfs patches is going to be based on their > resources to support the functionality. I would say "btrfs in Fedora" > needs a FESCo decision to set expectations and policy for the project. > Is it something that Fedora wants to offer and if so, what does that > look like? FESCo already voted 8 years ago to make Btrfs the default file system, and then allowed that to wither and become moot rather than revert the decision. Then later when the editions were created, part of Fedora.next, the decision of default file systems was handed to the working groups to decide. And the Fedora kernel team has also said this is a working group decision. The Fedora working group's technical specification states Btrfs is to be the default. Yet the working group has said it's uncomfortable taking action on this decision expressly because the Federal kernel team's official recommendation is to not recommend Btrfs. And I agree. I trust the Fedora kernel team as they've clearly stated limited resources and interest in Btrfs, the expectations and parameters for properly supporting Btrfs either as bug blocker worthy, and as a default file system from a user advocacy point of view. > If it's a best effort thing, then that makes it easier for > projects and contributors. Going back to Adam's original list, I would > suggest a FESCo decision like this should require explicit opt-in by the > user to enable btrfs functionality in the application in question. For > example, in the installer that could be enabled via a boot parameter (we > did this initially when btrfs functionality was first enabled in anaconda). That can only be considered to be a remarkable regression, not just in the context of Fedora, but in the context of the top 10 linux distributions all of which have visible Btrfs support in their GUI installers. Fedora's installer being the first to make Btrfs invisible by default would be a remarkable first indeed. > I'm not advocating one way or another for btrfs. But it seems we as a > project need a larger decision and policy around btrfs in general so we > can set expectations for users and developers. That decision and policy has already been made. Do you want it reverted? -- Chris Murphy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 7:49 AM Samantha Bueno wrote: > > On Fri, Aug 23, 2019 at 9:17 PM Adam Williamson > wrote: > > So...what should we do? Here are the options as I see 'em: > > > > 1. Keep supporting btrfs > > 2. Just modify the criterion with a btrfs exception, even if it's weird > > 3. Rewrite the criterion entirely > > 4. Keep btrfs support in the installer (and blivet-gui) but hide it as > > we used to - require a special boot argument for it to be visible > > 5. Drop btrfs support from the installer > This thread has diverged wildly into a lot of delightful > invective-slinging at my team. In the interest of getting back to the > original topic at hand: I would be in support of three -- five. This clearly means Btrfs related bugs in Fedora's Anaconda will not block release, and by extension Btrfs could not be the default file system either. "Btrfs is not a priority" does not at all answer the central question of what level of support and resources are expected to exist in the Fedora community to maintain Btrfs in both the bug blocking, and default file system contexts. I think Laura Abbott's emails on the kernel side are quite clear ground rules for serious Btrfs bugs to remain blocker worthy, along with a path to discuss any additional expectations for Btrfs to be a default file system in some capacity. Unqualified statements like "it is safe to say btrfs will not be the default" and "Btrfs is not a priority" and this 'zero chance Btrfs' comment [1] are completely compatible with assuming that no matter how much work is done by others, those things will not appear in Anaconda because the decision has been made, it is a fait accompli. It is very important to have clarity exactly to what degree Btrfs is not a priority. If the Anaconda team cannot state the terms and expectations for the #1 option in Adam's list, that's troubling. Again, I think it's completely fine if Red Hat Anaconda folks are disinterested in Btrfs, but it's a very different thing if there's resistance to it, and I'm getting a lot of language that is compatible with resisting Btrfs no matter what. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c10 -- Chris Murphy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Simple Firmware Interface being deprecated
On 8/27/19 8:46 AM, Hans de Goede wrote: Hi, On 27-08-19 09:14, Peter Robinson wrote: On Mon, Aug 26, 2019 at 9:27 PM Laura Abbott wrote: https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulw...@gmail.com/ menuconfig SFI bool "SFI (Simple Firmware Interface) Support" ---help--- The Simple Firmware Interface (SFI) provides a lightweight method for platform firmware to pass information to the operating system via static tables in memory. Kernel SFI support is required to boot on SFI-only platforms. Currently, all SFI-only platforms are based on the 2nd generation Intel Atom processor platform, code-named Moorestown. For more information, see http://simplefirmware.org Say 'Y' here to enable the kernel to boot on SFI-only platforms. I have no idea how common this is but Fedora does enable this option. If you are interested in salvaging this, please speak up! Grepping config and the kernel it seems Moorestown is the Intel MID platform and we explicitly disable X86_INTEL_MID so I'm not sure it's a problem. Yeah I'm pretty sure this is just for the Intel X86 "phone" SoCs which never went anywhere. As you know I've spend a lot of (spare) time on improving support for Intel Atom based hw (mainly Bay Trail and Cherry Trail tablets) and even I don't care for the phone chips, for one exactly because of SFI, instead of coming with EFI these phones come with some frankenstein firmware AFAIK, I never even bothered getting one to try and make it boot mainline ... TL;DR: I do not think this will missed, actually I think it should be fine to disable it in the Fedora kernels right away. I've just disabled it for the builds which I do from my personal kernel tree. It does not seem to affect any other Kconfig options. Regards, Hans Ah the x86 phone. Such dreams. Thanks for the confirmation Peter and Hans. I'm planning on dropping a bunch of stuff after 5.3 releases so I'll turn it off in rawhide there. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 8:57 AM Josh Boyer wrote: > > On Tue, Aug 27, 2019 at 8:48 AM Neal Gompa wrote: > > > > On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer > > wrote: > > > > > > On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa wrote: > > > > > > > > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer > > > > wrote: > > > > > > > > > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa wrote: > > > > > > > > > > > > On Tue, Aug 27, 2019 at 5:55 AM wrote: > > > > > > > > > > > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > > > > > > > On Mon, Aug 26, 2019 at 7:16 AM wrote: > > > > > > > > > > > > > > > > > > I understand them. The point is, for them and even us (the > > > > > > > > > installer) > > > > > > > > > is work on BTRFS not a priority. It's something we can't > > > > > > > > > benefit on > > > > > > > > > RHEL and it could be almost completely replaced by LVM + xfs > > > > > > > > > solution. > > > > > > > > > However, it still giving us bugs and making our test surface > > > > > > > > > bigger. > > > > > > > > > > > > > > > > > > > From the Anaconda team PoV it would make our lives easier > > > > > > > > > > to not > > > > > > > > > support BTRFS at all. I'm not saying that we should drop > > > > > > > > > BTRFS in > > > > > > > > > Fedora, only that it would be easier for Anaconda team to be > > > > > > > > > without > > > > > > > > > that on Fedora. > > > > > > > > > > > > > > > > This is flat-out a trap. This is what makes Anaconda such a > > > > > > > > failure > > > > > > > > as > > > > > > > > a community project. Why does the past (RHEL) affect the > > > > > > > > present and > > > > > > > > future (Fedora)? There's basically no way whatsoever to make > > > > > > > > anything > > > > > > > > better with this logic. The Anaconda releases that any > > > > > > > > improvements > > > > > > > > would be going into aren't even landing into the RHEL 8 branch > > > > > > > > that > > > > > > > > governs the latest iteration of Fedora's past. From any > > > > > > > > reasonable > > > > > > > > person's perspective, this answer makes no sense unless you're > > > > > > > > using > > > > > > > > RHEL as an excuse to not support Fedora. > > > > > > > > > > > > > > > > > > > > > > RHEL is not the past. Everything we do we have to think that it > > > > > > > will go > > > > > > > to RHEL and if it is Fedora specific we have to create a way to > > > > > > > disable > > > > > > > the functionality for another RHEL branching. And yes, we have a > > > > > > > few > > > > > > > things (not only a BTRFS) specific to Fedora the same way as a few > > > > > > > things specific to RHEL which are disabled on Fedora. > > > > > > > > > > > > > > And as I wrote before, I'm not saying that we will remove the > > > > > > > BTRFS > > > > > > > support from Fedora. The point is that making the list specific to > > > > > > > releases smaller will make our live easier. > > > > > > > > > > > > > > > > > > > By definition, RHEL *is* the past from a Fedora context. It's forked > > > > > > from an old version of Fedora that's not supported anymore. It is > > > > > > the > > > > > > result of decisions that aren't supposed to apply to Fedora. And it > > > > > > is > > > > > > the result of a different bias that should never apply to Fedora if > > > > > > the RH ecosystem is supposed to be able to evolve. > > > > > > > > > > There is always the *next* RHEL. Or, if you want to remove a product > > > > > context, the next enterprise operating system derived from Fedora. > > > > > RHEL/enterprise is both past and future and Fedora focuses on the > > > > > future. You cannot dismiss enterprise as a target by waiving it away > > > > > as "past". > > > > > > > > > > > > > Until there's a branch in Anaconda's git for the next version of RHEL, > > > > it doesn't exist yet. I'm sure people are *thinking* about it, but > > > > it's obviously on the back burner for a little while. I would expect > > > > to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now > > > > it doesn't exist. > > > > > > In 1.5 years is entirely too late. Massively so. I know people think > > > we're paying lip-service to upstream when discussing Fedora and RHEL, > > > but even with a terrible "import once" model the code being developed > > > in Fedora right now will materially land in RHEL 9. Your presumption > > > on a branch needing to exist is simply incorrect. > > > > > > > For us non RH people, there's nothing for us to do about RHEL 9 right > > now. Your planning is done in secret, and there's little to no > > community feedback loop for RHEL.next. I agree that in ordinary > > circumstances, it's too late once the branch has happened, because > > usually that means it's the stabilizing phase. But there's nothing I > > can do before then. > > I think that's a problem and one which we're trying to address. > However, whether code lands due to internal planning or due to > community contribution, it all still impacts any
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 8:48 AM Neal Gompa wrote: > > On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer wrote: > > > > On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa wrote: > > > > > > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer > > > wrote: > > > > > > > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa wrote: > > > > > > > > > > On Tue, Aug 27, 2019 at 5:55 AM wrote: > > > > > > > > > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > > > > > > On Mon, Aug 26, 2019 at 7:16 AM wrote: > > > > > > > > > > > > > > > > I understand them. The point is, for them and even us (the > > > > > > > > installer) > > > > > > > > is work on BTRFS not a priority. It's something we can't > > > > > > > > benefit on > > > > > > > > RHEL and it could be almost completely replaced by LVM + xfs > > > > > > > > solution. > > > > > > > > However, it still giving us bugs and making our test surface > > > > > > > > bigger. > > > > > > > > > > > > > > > > > From the Anaconda team PoV it would make our lives easier to > > > > > > > > > not > > > > > > > > support BTRFS at all. I'm not saying that we should drop BTRFS > > > > > > > > in > > > > > > > > Fedora, only that it would be easier for Anaconda team to be > > > > > > > > without > > > > > > > > that on Fedora. > > > > > > > > > > > > > > This is flat-out a trap. This is what makes Anaconda such a > > > > > > > failure > > > > > > > as > > > > > > > a community project. Why does the past (RHEL) affect the present > > > > > > > and > > > > > > > future (Fedora)? There's basically no way whatsoever to make > > > > > > > anything > > > > > > > better with this logic. The Anaconda releases that any > > > > > > > improvements > > > > > > > would be going into aren't even landing into the RHEL 8 branch > > > > > > > that > > > > > > > governs the latest iteration of Fedora's past. From any reasonable > > > > > > > person's perspective, this answer makes no sense unless you're > > > > > > > using > > > > > > > RHEL as an excuse to not support Fedora. > > > > > > > > > > > > > > > > > > > RHEL is not the past. Everything we do we have to think that it > > > > > > will go > > > > > > to RHEL and if it is Fedora specific we have to create a way to > > > > > > disable > > > > > > the functionality for another RHEL branching. And yes, we have a few > > > > > > things (not only a BTRFS) specific to Fedora the same way as a few > > > > > > things specific to RHEL which are disabled on Fedora. > > > > > > > > > > > > And as I wrote before, I'm not saying that we will remove the BTRFS > > > > > > support from Fedora. The point is that making the list specific to > > > > > > releases smaller will make our live easier. > > > > > > > > > > > > > > > > By definition, RHEL *is* the past from a Fedora context. It's forked > > > > > from an old version of Fedora that's not supported anymore. It is the > > > > > result of decisions that aren't supposed to apply to Fedora. And it is > > > > > the result of a different bias that should never apply to Fedora if > > > > > the RH ecosystem is supposed to be able to evolve. > > > > > > > > There is always the *next* RHEL. Or, if you want to remove a product > > > > context, the next enterprise operating system derived from Fedora. > > > > RHEL/enterprise is both past and future and Fedora focuses on the > > > > future. You cannot dismiss enterprise as a target by waiving it away > > > > as "past". > > > > > > > > > > Until there's a branch in Anaconda's git for the next version of RHEL, > > > it doesn't exist yet. I'm sure people are *thinking* about it, but > > > it's obviously on the back burner for a little while. I would expect > > > to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now > > > it doesn't exist. > > > > In 1.5 years is entirely too late. Massively so. I know people think > > we're paying lip-service to upstream when discussing Fedora and RHEL, > > but even with a terrible "import once" model the code being developed > > in Fedora right now will materially land in RHEL 9. Your presumption > > on a branch needing to exist is simply incorrect. > > > > For us non RH people, there's nothing for us to do about RHEL 9 right > now. Your planning is done in secret, and there's little to no > community feedback loop for RHEL.next. I agree that in ordinary > circumstances, it's too late once the branch has happened, because > usually that means it's the stabilizing phase. But there's nothing I > can do before then. I think that's a problem and one which we're trying to address. However, whether code lands due to internal planning or due to community contribution, it all still impacts any future OS release, Fedora and enterprise alike. > > > > > From the way you describe it, Fedora is just something occasionally > > > > > give lip service to while your main focus is RHEL. That's fine, but > > > > > that is a problem for the Fedora context. > > > > > > > > Neal, I don't understand. The source code to anaconda is
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer wrote: > > On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa wrote: > > > > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer > > wrote: > > > > > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa wrote: > > > > > > > > On Tue, Aug 27, 2019 at 5:55 AM wrote: > > > > > > > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > > > > > On Mon, Aug 26, 2019 at 7:16 AM wrote: > > > > > > > > > > > > > > I understand them. The point is, for them and even us (the > > > > > > > installer) > > > > > > > is work on BTRFS not a priority. It's something we can't benefit > > > > > > > on > > > > > > > RHEL and it could be almost completely replaced by LVM + xfs > > > > > > > solution. > > > > > > > However, it still giving us bugs and making our test surface > > > > > > > bigger. > > > > > > > > > > > > > > > From the Anaconda team PoV it would make our lives easier to not > > > > > > > support BTRFS at all. I'm not saying that we should drop BTRFS in > > > > > > > Fedora, only that it would be easier for Anaconda team to be > > > > > > > without > > > > > > > that on Fedora. > > > > > > > > > > > > This is flat-out a trap. This is what makes Anaconda such a failure > > > > > > as > > > > > > a community project. Why does the past (RHEL) affect the present and > > > > > > future (Fedora)? There's basically no way whatsoever to make > > > > > > anything > > > > > > better with this logic. The Anaconda releases that any improvements > > > > > > would be going into aren't even landing into the RHEL 8 branch that > > > > > > governs the latest iteration of Fedora's past. From any reasonable > > > > > > person's perspective, this answer makes no sense unless you're using > > > > > > RHEL as an excuse to not support Fedora. > > > > > > > > > > > > > > > > RHEL is not the past. Everything we do we have to think that it will > > > > > go > > > > > to RHEL and if it is Fedora specific we have to create a way to > > > > > disable > > > > > the functionality for another RHEL branching. And yes, we have a few > > > > > things (not only a BTRFS) specific to Fedora the same way as a few > > > > > things specific to RHEL which are disabled on Fedora. > > > > > > > > > > And as I wrote before, I'm not saying that we will remove the BTRFS > > > > > support from Fedora. The point is that making the list specific to > > > > > releases smaller will make our live easier. > > > > > > > > > > > > > By definition, RHEL *is* the past from a Fedora context. It's forked > > > > from an old version of Fedora that's not supported anymore. It is the > > > > result of decisions that aren't supposed to apply to Fedora. And it is > > > > the result of a different bias that should never apply to Fedora if > > > > the RH ecosystem is supposed to be able to evolve. > > > > > > There is always the *next* RHEL. Or, if you want to remove a product > > > context, the next enterprise operating system derived from Fedora. > > > RHEL/enterprise is both past and future and Fedora focuses on the > > > future. You cannot dismiss enterprise as a target by waiving it away > > > as "past". > > > > > > > Until there's a branch in Anaconda's git for the next version of RHEL, > > it doesn't exist yet. I'm sure people are *thinking* about it, but > > it's obviously on the back burner for a little while. I would expect > > to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now > > it doesn't exist. > > In 1.5 years is entirely too late. Massively so. I know people think > we're paying lip-service to upstream when discussing Fedora and RHEL, > but even with a terrible "import once" model the code being developed > in Fedora right now will materially land in RHEL 9. Your presumption > on a branch needing to exist is simply incorrect. > For us non RH people, there's nothing for us to do about RHEL 9 right now. Your planning is done in secret, and there's little to no community feedback loop for RHEL.next. I agree that in ordinary circumstances, it's too late once the branch has happened, because usually that means it's the stabilizing phase. But there's nothing I can do before then. > > > > From the way you describe it, Fedora is just something occasionally > > > > give lip service to while your main focus is RHEL. That's fine, but > > > > that is a problem for the Fedora context. > > > > > > Neal, I don't understand. The source code to anaconda is available. > > > What is preventing you from taking it and making a micro-fork that > > > does better btrfs enablement, and packaging that in Fedora and using > > > it in a spin? > > > > > > > I have seriously contemplated it. It isn't the first time I've done a > > fork because I had to[1]. > > > > But the main reason I don't do it is because it will cause more damage > > in the Fedora community by doing so. Two sets of packages for Anaconda > > that all the things that depend on Anaconda could cause a huge level > > of breakage because the two versions must
Re: Simple Firmware Interface being deprecated
Hi, On 27-08-19 09:14, Peter Robinson wrote: On Mon, Aug 26, 2019 at 9:27 PM Laura Abbott wrote: https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulw...@gmail.com/ menuconfig SFI bool "SFI (Simple Firmware Interface) Support" ---help--- The Simple Firmware Interface (SFI) provides a lightweight method for platform firmware to pass information to the operating system via static tables in memory. Kernel SFI support is required to boot on SFI-only platforms. Currently, all SFI-only platforms are based on the 2nd generation Intel Atom processor platform, code-named Moorestown. For more information, see http://simplefirmware.org Say 'Y' here to enable the kernel to boot on SFI-only platforms. I have no idea how common this is but Fedora does enable this option. If you are interested in salvaging this, please speak up! Grepping config and the kernel it seems Moorestown is the Intel MID platform and we explicitly disable X86_INTEL_MID so I'm not sure it's a problem. Yeah I'm pretty sure this is just for the Intel X86 "phone" SoCs which never went anywhere. As you know I've spend a lot of (spare) time on improving support for Intel Atom based hw (mainly Bay Trail and Cherry Trail tablets) and even I don't care for the phone chips, for one exactly because of SFI, instead of coming with EFI these phones come with some frankenstein firmware AFAIK, I never even bothered getting one to try and make it boot mainline ... TL;DR: I do not think this will missed, actually I think it should be fine to disable it in the Fedora kernels right away. I've just disabled it for the builds which I do from my personal kernel tree. It does not seem to affect any other Kconfig options. Regards, Hans ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa wrote: > > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer wrote: > > > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa wrote: > > > > > > On Tue, Aug 27, 2019 at 5:55 AM wrote: > > > > > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > > > > On Mon, Aug 26, 2019 at 7:16 AM wrote: > > > > > > > > > > > > I understand them. The point is, for them and even us (the > > > > > > installer) > > > > > > is work on BTRFS not a priority. It's something we can't benefit on > > > > > > RHEL and it could be almost completely replaced by LVM + xfs > > > > > > solution. > > > > > > However, it still giving us bugs and making our test surface > > > > > > bigger. > > > > > > > > > > > > > From the Anaconda team PoV it would make our lives easier to not > > > > > > support BTRFS at all. I'm not saying that we should drop BTRFS in > > > > > > Fedora, only that it would be easier for Anaconda team to be > > > > > > without > > > > > > that on Fedora. > > > > > > > > > > This is flat-out a trap. This is what makes Anaconda such a failure > > > > > as > > > > > a community project. Why does the past (RHEL) affect the present and > > > > > future (Fedora)? There's basically no way whatsoever to make anything > > > > > better with this logic. The Anaconda releases that any improvements > > > > > would be going into aren't even landing into the RHEL 8 branch that > > > > > governs the latest iteration of Fedora's past. From any reasonable > > > > > person's perspective, this answer makes no sense unless you're using > > > > > RHEL as an excuse to not support Fedora. > > > > > > > > > > > > > RHEL is not the past. Everything we do we have to think that it will go > > > > to RHEL and if it is Fedora specific we have to create a way to disable > > > > the functionality for another RHEL branching. And yes, we have a few > > > > things (not only a BTRFS) specific to Fedora the same way as a few > > > > things specific to RHEL which are disabled on Fedora. > > > > > > > > And as I wrote before, I'm not saying that we will remove the BTRFS > > > > support from Fedora. The point is that making the list specific to > > > > releases smaller will make our live easier. > > > > > > > > > > By definition, RHEL *is* the past from a Fedora context. It's forked > > > from an old version of Fedora that's not supported anymore. It is the > > > result of decisions that aren't supposed to apply to Fedora. And it is > > > the result of a different bias that should never apply to Fedora if > > > the RH ecosystem is supposed to be able to evolve. > > > > There is always the *next* RHEL. Or, if you want to remove a product > > context, the next enterprise operating system derived from Fedora. > > RHEL/enterprise is both past and future and Fedora focuses on the > > future. You cannot dismiss enterprise as a target by waiving it away > > as "past". > > > > Until there's a branch in Anaconda's git for the next version of RHEL, > it doesn't exist yet. I'm sure people are *thinking* about it, but > it's obviously on the back burner for a little while. I would expect > to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now > it doesn't exist. In 1.5 years is entirely too late. Massively so. I know people think we're paying lip-service to upstream when discussing Fedora and RHEL, but even with a terrible "import once" model the code being developed in Fedora right now will materially land in RHEL 9. Your presumption on a branch needing to exist is simply incorrect. > > > From the way you describe it, Fedora is just something occasionally > > > give lip service to while your main focus is RHEL. That's fine, but > > > that is a problem for the Fedora context. > > > > Neal, I don't understand. The source code to anaconda is available. > > What is preventing you from taking it and making a micro-fork that > > does better btrfs enablement, and packaging that in Fedora and using > > it in a spin? > > > > I have seriously contemplated it. It isn't the first time I've done a > fork because I had to[1]. > > But the main reason I don't do it is because it will cause more damage > in the Fedora community by doing so. Two sets of packages for Anaconda > that all the things that depend on Anaconda could cause a huge level > of breakage because the two versions must *always* be drop-in > replacements for each other. If they're not, it makes it impossible to > leverage the Fedora tooling to do things like making spins and such. I > don't even *know* what kind of work it would entail if I wanted it to > be an official spin composed through pungi. I'm pretty sure the releng > folks would kill me for doing that, as now pungi would have be aware > and switch anaconda packages for lorax... So... more time investment. Yep. > Additionally, it would require a fork of pykickstart so that further > enhancements to the Btrfs partitioning can be defined. However, *that* > causes bigger problems because now
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa wrote: > > On Tue, Aug 27, 2019 at 5:55 AM wrote: > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > > On Mon, Aug 26, 2019 at 7:16 AM wrote: > > > > > > > > I understand them. The point is, for them and even us (the > > > > installer) > > > > is work on BTRFS not a priority. It's something we can't benefit on > > > > RHEL and it could be almost completely replaced by LVM + xfs > > > > solution. > > > > However, it still giving us bugs and making our test surface > > > > bigger. > > > > > > > > > From the Anaconda team PoV it would make our lives easier to not > > > > support BTRFS at all. I'm not saying that we should drop BTRFS in > > > > Fedora, only that it would be easier for Anaconda team to be > > > > without > > > > that on Fedora. > > > > > > This is flat-out a trap. This is what makes Anaconda such a failure > > > as > > > a community project. Why does the past (RHEL) affect the present and > > > future (Fedora)? There's basically no way whatsoever to make anything > > > better with this logic. The Anaconda releases that any improvements > > > would be going into aren't even landing into the RHEL 8 branch that > > > governs the latest iteration of Fedora's past. From any reasonable > > > person's perspective, this answer makes no sense unless you're using > > > RHEL as an excuse to not support Fedora. > > > > > > > RHEL is not the past. Everything we do we have to think that it will go > > to RHEL and if it is Fedora specific we have to create a way to disable > > the functionality for another RHEL branching. And yes, we have a few > > things (not only a BTRFS) specific to Fedora the same way as a few > > things specific to RHEL which are disabled on Fedora. > > > > And as I wrote before, I'm not saying that we will remove the BTRFS > > support from Fedora. The point is that making the list specific to > > releases smaller will make our live easier. > > > > By definition, RHEL *is* the past from a Fedora context. It's forked > from an old version of Fedora that's not supported anymore. It is the > result of decisions that aren't supposed to apply to Fedora. And it is > the result of a different bias that should never apply to Fedora if > the RH ecosystem is supposed to be able to evolve. There is always the *next* RHEL. Or, if you want to remove a product context, the next enterprise operating system derived from Fedora. RHEL/enterprise is both past and future and Fedora focuses on the future. You cannot dismiss enterprise as a target by waiving it away as "past". > From the way you describe it, Fedora is just something occasionally > give lip service to while your main focus is RHEL. That's fine, but > that is a problem for the Fedora context. Neal, I don't understand. The source code to anaconda is available. What is preventing you from taking it and making a micro-fork that does better btrfs enablement, and packaging that in Fedora and using it in a spin? My guess would be that you perhaps don't have the time to do that. That's reasonable. I can say, with no uncertainty, that the anaconda team doesn't have time to do it either. The day to day things that team is working on far outweigh btrfs as a priority, even in Fedora. This team literally gets dozens of completely unrelated bugs they have to look at and triage simply because it is the first thing people interact with when they install the OS. It's a catch-all. Btrfs enablement would continually sit on the back burner waiting to get done. Before you think I'm being naive or disingenuous, I'm truly not. I understand the frustration of wanting to get code into a project or product that isn't willing to take that code. However, it's not only about the code. The code review and acceptance isn't the end of the time investment. It is the start. There's test cases, test infrastructure, debugging support issues, on-going code changes and refactoring, etc etc. One of the ways to limit these impacts is to be selective in what enablement you choose to bring into a project. That is what the anaconda team is doing here. The beauty (and ugly!) of open source is that you can still take the code and do what you want if you are willing to make that investment. josh ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 5:55 AM wrote: > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > On Mon, Aug 26, 2019 at 7:16 AM wrote: > > > > > > I understand them. The point is, for them and even us (the > > > installer) > > > is work on BTRFS not a priority. It's something we can't benefit on > > > RHEL and it could be almost completely replaced by LVM + xfs > > > solution. > > > However, it still giving us bugs and making our test surface > > > bigger. > > > > > > > From the Anaconda team PoV it would make our lives easier to not > > > support BTRFS at all. I'm not saying that we should drop BTRFS in > > > Fedora, only that it would be easier for Anaconda team to be > > > without > > > that on Fedora. > > > > This is flat-out a trap. This is what makes Anaconda such a failure > > as > > a community project. Why does the past (RHEL) affect the present and > > future (Fedora)? There's basically no way whatsoever to make anything > > better with this logic. The Anaconda releases that any improvements > > would be going into aren't even landing into the RHEL 8 branch that > > governs the latest iteration of Fedora's past. From any reasonable > > person's perspective, this answer makes no sense unless you're using > > RHEL as an excuse to not support Fedora. > > > > RHEL is not the past. Everything we do we have to think that it will go > to RHEL and if it is Fedora specific we have to create a way to disable > the functionality for another RHEL branching. And yes, we have a few > things (not only a BTRFS) specific to Fedora the same way as a few > things specific to RHEL which are disabled on Fedora. > > And as I wrote before, I'm not saying that we will remove the BTRFS > support from Fedora. The point is that making the list specific to > releases smaller will make our live easier. > By definition, RHEL *is* the past from a Fedora context. It's forked from an old version of Fedora that's not supported anymore. It is the result of decisions that aren't supposed to apply to Fedora. And it is the result of a different bias that should never apply to Fedora if the RH ecosystem is supposed to be able to evolve. From the way you describe it, Fedora is just something occasionally give lip service to while your main focus is RHEL. That's fine, but that is a problem for the Fedora context. -- 真実はいつも一つ！/ Always, there's only one truth! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Re: Simple Firmware Interface being deprecated
On Mon, Aug 26, 2019 at 9:27 PM Laura Abbott wrote: > > https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulw...@gmail.com/ > > menuconfig SFI > bool "SFI (Simple Firmware Interface) Support" > ---help--- > The Simple Firmware Interface (SFI) provides a lightweight method > for platform firmware to pass information to the operating system > via static tables in memory. Kernel SFI support is required to > boot on SFI-only platforms. Currently, all SFI-only platforms are > based on the 2nd generation Intel Atom processor platform, > code-named Moorestown. > > For more information, see http://simplefirmware.org > > Say 'Y' here to enable the kernel to boot on SFI-only platforms. > > I have no idea how common this is but Fedora does enable this option. > If you are interested in salvaging this, please speak up! Grepping config and the kernel it seems Moorestown is the Intel MID platform and we explicitly disable X86_INTEL_MID so I'm not sure it's a problem. P ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
