Re: Discussion: what would not blocking on btrfs look like?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- 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




[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux