On Tue, Aug 27, 2019 at 5:55 AM jkonecny@redhat.com wrote:
On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
On Mon, Aug 26, 2019 at 7:16 AM jkonecny@redhat.com 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.
On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 5:55 AM jkonecny@redhat.com wrote:
On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
On Mon, Aug 26, 2019 at 7:16 AM jkonecny@redhat.com 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
On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 5:55 AM jkonecny@redhat.com wrote:
On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
On Mon, Aug 26, 2019 at 7:16 AM jkonecny@redhat.com 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.
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...
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 there's incompatible grammar. Given how poorly the pykickstart project is run right now, it might even make sense to fully fork it, except that it fragments a specification defined in implementation (kickstart files).
I've looked at writing automation to watch Anaconda and pykickstart and continuously integrate patchsets on top for a forked package set. But in the end, it would be too destructive for the Fedora community to do so.
[1]: https://lists.fedoraproject.org/archives/list/livecd@lists.fedoraproject.org...
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.
I *know* the Anaconda team barely has bandwidth right now. That is a function of them being too closed for a community to develop around it. That is *entirely* their fault. The Anaconda engineers, the team leads, the managers, and the project/product owners for Anaconda do not value the community enough to allow one to develop.
(I've met a fair number of Anaconda developers and manager folks, I know this is the case, even if they don't entirely realize it themselves.)
There are several distributions in the RH ecosystem that use Anaconda, and yet only a team of ~3 people are allowed to do anything on it? That seems brutally useless. Then again, we have the same problem with Koji. Terminally understaffing is not useful. And because the community cannot contribute to Anaconda, if there are bugs, there's no way for the community to help fix them.
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.
Honestly, this goes back to Anaconda being a horrifically managed project. Where is the contribution criteria? Where is the onboarding process for more people to be involved?
I'm proficient in Python. I work in plumbing code all the time. Tell me what I need to do to make my feature possible! Let me see the test feedback in my pull request so that I can act on it! Give me (and other interested folks) the ability to contribute to the success of Anaconda!
On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 5:55 AM jkonecny@redhat.com wrote:
On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
On Mon, Aug 26, 2019 at 7:16 AM jkonecny@redhat.com 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 there's incompatible grammar. Given how poorly the pykickstart project is run right now, it might even make sense to fully fork it, except that it fragments a specification defined in implementation (kickstart files).
I agree on this one. It would be great if someone created a canonical specification for both kickstarts and comps.
I've looked at writing automation to watch Anaconda and pykickstart and continuously integrate patchsets on top for a forked package set. But in the end, it would be too destructive for the Fedora community to do so.
I'll disagree, but only in severity. It would certainly be inconvenient.
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.
I *know* the Anaconda team barely has bandwidth right now. That is a function of them being too closed for a community to develop around it. That is *entirely* their fault. The Anaconda engineers, the team leads, the managers, and the project/product owners for Anaconda do not value the community enough to allow one to develop.
(I've met a fair number of Anaconda developers and manager folks, I know this is the case, even if they don't entirely realize it themselves.)
I think you're conflating "selective in what they accept" and "do not value community".
There are several distributions in the RH ecosystem that use Anaconda, and yet only a team of ~3 people are allowed to do anything on it? That seems brutally useless. Then again, we have the same problem with Koji. Terminally understaffing is not useful. And because the community cannot contribute to Anaconda, if there are bugs, there's no way for the community to help fix them.
There certainly is. You submit a PR. It's what they would do. That PR being merged or not is a completely different topic than the ability to submit it in the first place.
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.
Honestly, this goes back to Anaconda being a horrifically managed project. Where is the contribution criteria? Where is the onboarding process for more people to be involved?
I mean, if you want to materially help free up time for that team to do project on-boarding, developer education, and code review you could always volunteer to do all their bug triage. Nobody wants to do the crap work though, so you're just asking for more things they don't have time to properly document.
Or you could document it for them and see what they think?
I'm proficient in Python. I work in plumbing code all the time. Tell me what I need to do to make my feature possible! Let me see the test feedback in my pull request so that I can act on it! Give me (and other interested folks) the ability to contribute to the success of Anaconda!
This is not hard. You're trending to hyperbole, which is always fun. So let's bring it back to concrete steps: You submit PRs. Submit them with testcases. Submit them with documentation. If it's something the project wants to accept, great. If it isn't, they'll tell you. Remember, determining what contributes to the success of the project is up to the project owners. Dealing with rejection can be hard for anyone, but it's not a statement on you or your work. It normally winds up being about what the project is trying to do and what it wants to support.
josh
On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 5:55 AM jkonecny@redhat.com wrote:
On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
On Mon, Aug 26, 2019 at 7:16 AM jkonecny@redhat.com 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 *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 there's incompatible grammar. Given how poorly the pykickstart project is run right now, it might even make sense to fully fork it, except that it fragments a specification defined in implementation (kickstart files).
I agree on this one. It would be great if someone created a canonical specification for both kickstarts and comps.
Comps isn't *quite* so bad off. There's a DTD for it, at least. I've collected most of the RPM-MD repodata specification files that I could find into a single repo: https://pagure.io/rpm-metadata
Someday, maybe those documents can be rationalized into a formal spec, but there are bigger fish to fry in that realm right now...
I've looked at writing automation to watch Anaconda and pykickstart and continuously integrate patchsets on top for a forked package set. But in the end, it would be too destructive for the Fedora community to do so.
I'll disagree, but only in severity. It would certainly be inconvenient.
It sends a bad message as well: "Fedora developers have to fork their own installer because installer developers can't work with Fedora developers."
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.
I *know* the Anaconda team barely has bandwidth right now. That is a function of them being too closed for a community to develop around it. That is *entirely* their fault. The Anaconda engineers, the team leads, the managers, and the project/product owners for Anaconda do not value the community enough to allow one to develop.
(I've met a fair number of Anaconda developers and manager folks, I know this is the case, even if they don't entirely realize it themselves.)
I think you're conflating "selective in what they accept" and "do not value community".
There are several distributions in the RH ecosystem that use Anaconda, and yet only a team of ~3 people are allowed to do anything on it? That seems brutally useless. Then again, we have the same problem with Koji. Terminally understaffing is not useful. And because the community cannot contribute to Anaconda, if there are bugs, there's no way for the community to help fix them.
There certainly is. You submit a PR. It's what they would do. That PR being merged or not is a completely different topic than the ability to submit it in the first place.
There *was* a PR submitted. It was even a one-liner because the contributor fixed the underlying problem elsewhere. It's been in limbo for over a year: https://github.com/rhinstaller/anaconda/pull/1375
You seem to think that I'm just shouting without any effort to back it up. There was originally four of us working on this two years ago. It's dwindled over time as the roadblocks were thrown up time and time again.
On Tue, Aug 27, 2019 at 8:48 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 5:55 AM jkonecny@redhat.com wrote:
On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > On Mon, Aug 26, 2019 at 7:16 AM jkonecny@redhat.com 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 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 there's incompatible grammar. Given how poorly the pykickstart project is run right now, it might even make sense to fully fork it, except that it fragments a specification defined in implementation (kickstart files).
I agree on this one. It would be great if someone created a canonical specification for both kickstarts and comps.
Comps isn't *quite* so bad off. There's a DTD for it, at least. I've collected most of the RPM-MD repodata specification files that I could find into a single repo: https://pagure.io/rpm-metadata
Someday, maybe those documents can be rationalized into a formal spec, but there are bigger fish to fry in that realm right now...
So you've made a priority call? :)
I've looked at writing automation to watch Anaconda and pykickstart and continuously integrate patchsets on top for a forked package set. But in the end, it would be too destructive for the Fedora community to do so.
I'll disagree, but only in severity. It would certainly be inconvenient.
It sends a bad message as well: "Fedora developers have to fork their own installer because installer developers can't work with Fedora developers."
Generalization again.
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.
I *know* the Anaconda team barely has bandwidth right now. That is a function of them being too closed for a community to develop around it. That is *entirely* their fault. The Anaconda engineers, the team leads, the managers, and the project/product owners for Anaconda do not value the community enough to allow one to develop.
(I've met a fair number of Anaconda developers and manager folks, I know this is the case, even if they don't entirely realize it themselves.)
I think you're conflating "selective in what they accept" and "do not value community".
There are several distributions in the RH ecosystem that use Anaconda, and yet only a team of ~3 people are allowed to do anything on it? That seems brutally useless. Then again, we have the same problem with Koji. Terminally understaffing is not useful. And because the community cannot contribute to Anaconda, if there are bugs, there's no way for the community to help fix them.
There certainly is. You submit a PR. It's what they would do. That PR being merged or not is a completely different topic than the ability to submit it in the first place.
There *was* a PR submitted. It was even a one-liner because the contributor fixed the underlying problem elsewhere. It's been in limbo for over a year: https://github.com/rhinstaller/anaconda/pull/1375
You seem to think that I'm just shouting without any effort to back it up. There was originally four of us working on this two years ago. It's dwindled over time as the roadblocks were thrown up time and time again.
No, I don't think that at all. I think you've taken that PR, which was rejected because the project doesn't want to do more btrfs enablement, and generalized it to "nobody can contribute to anaconda". That's my point. You're using hyperbole as an argument for something specific.
If you have other PRs that were general bug fixes or unrelated to btrfs which were rejected, I think it would be refreshing for all involved to look at why again. That would indicate a contribution model problem to me. Not a single feature/PR the project doesn't want to include.
josh
On Tue, Aug 27, 2019 at 8:57 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 8:48 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 27, 2019 at 5:55 AM jkonecny@redhat.com wrote: > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > On Mon, Aug 26, 2019 at 7:16 AM jkonecny@redhat.com 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 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 there's incompatible grammar. Given how poorly the pykickstart project is run right now, it might even make sense to fully fork it, except that it fragments a specification defined in implementation (kickstart files).
I agree on this one. It would be great if someone created a canonical specification for both kickstarts and comps.
Comps isn't *quite* so bad off. There's a DTD for it, at least. I've collected most of the RPM-MD repodata specification files that I could find into a single repo: https://pagure.io/rpm-metadata
Someday, maybe those documents can be rationalized into a formal spec, but there are bigger fish to fry in that realm right now...
So you've made a priority call? :)
I've looked at writing automation to watch Anaconda and pykickstart and continuously integrate patchsets on top for a forked package set. But in the end, it would be too destructive for the Fedora community to do so.
I'll disagree, but only in severity. It would certainly be inconvenient.
It sends a bad message as well: "Fedora developers have to fork their own installer because installer developers can't work with Fedora developers."
Generalization again.
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.
I *know* the Anaconda team barely has bandwidth right now. That is a function of them being too closed for a community to develop around it. That is *entirely* their fault. The Anaconda engineers, the team leads, the managers, and the project/product owners for Anaconda do not value the community enough to allow one to develop.
(I've met a fair number of Anaconda developers and manager folks, I know this is the case, even if they don't entirely realize it themselves.)
I think you're conflating "selective in what they accept" and "do not value community".
There are several distributions in the RH ecosystem that use Anaconda, and yet only a team of ~3 people are allowed to do anything on it? That seems brutally useless. Then again, we have the same problem with Koji. Terminally understaffing is not useful. And because the community cannot contribute to Anaconda, if there are bugs, there's no way for the community to help fix them.
There certainly is. You submit a PR. It's what they would do. That PR being merged or not is a completely different topic than the ability to submit it in the first place.
There *was* a PR submitted. It was even a one-liner because the contributor fixed the underlying problem elsewhere. It's been in limbo for over a year: https://github.com/rhinstaller/anaconda/pull/1375
You seem to think that I'm just shouting without any effort to back it up. There was originally four of us working on this two years ago. It's dwindled over time as the roadblocks were thrown up time and time again.
No, I don't think that at all. I think you've taken that PR, which was rejected because the project doesn't want to do more btrfs enablement, and generalized it to "nobody can contribute to anaconda". That's my point. You're using hyperbole as an argument for something specific.
If you have other PRs that were general bug fixes or unrelated to btrfs which were rejected, I think it would be refreshing for all involved to look at why again. That would indicate a contribution model problem to me. Not a single feature/PR the project doesn't want to include.
If it was just that, I'd agree with you.
But other people have had similar "limbo PR" problems for other features. The gpgkey and repo priority support for repositories in pykickstart and anaconda are other examples.
And even my attempt to proactively fix Anaconda to exclude packages correctly took quite a long time to get through. Over six months before getting feedback, and that only happened because I nagged people on IRC to look at it to fix other problems. Trying to fix something *before* it becomes a problem is an exercise in futility. It only got looked at once we started having problems in media creation and net installer.
Anaconda definitely has a problem.
kernel@lists.fedoraproject.org
-
Josh Boyer -
Neal Gompa