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

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



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


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