----- Original Message ----- > From: "Neal Gompa" <ngompa13@xxxxxxxxx> > To: "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> > Cc: "For testing and quality assurance of Fedora releases" <test@xxxxxxxxxxxxxxxxxxxxxxx>, "kernel" > <kernel@xxxxxxxxxxxxxxxxxxxxxxx>, "Discussion of Development and Customization of the Red Hat Linux Installer" > <anaconda-devel-list@xxxxxxxxxx> > Sent: Tuesday, August 27, 2019 2:09:41 PM > Subject: Re: Discussion: what would not blocking on btrfs look like? > > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > On Tue, Aug 27, 2019 at 5:55 AM <jkonecny@xxxxxxxxxx> wrote: > > > > > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > > > > On Mon, Aug 26, 2019 at 7:16 AM <jkonecny@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/thread/VL666ET5FR6MTSGGTHDULDSQN5DEWUUM/ > > > 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? We have contribution guidelines as part of the Anaconda documentation on Read the Docs: https://anaconda-installer.readthedocs.io/en/latest/contributing.html Please let us know if you see something there that is incorrect or out of date (that can always happen). >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! > > > -- > 真実はいつも一つ!/ Always, there's only one truth! > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list