On 8/27/19 12:07 PM, Adam Williamson wrote:
On Tue, 2019-08-27 at 08:57 -0400, Josh Boyer wrote:
>
>> 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, to be fair, I can see Neal's point here. In a way you seem to be
kinda sending him in circles here: "anaconda team doesn't have the
time/resources to invest in btrfs development, but you can help by
sending them pull requests. Oh, you sent them a pull request and they
rejected it? Well, it's because they don't have time/resources for
btrfs development..." You're right that one rejected PR doesn't
necessarily indicate a contribution model problem, but putting the
wider issue aside, a very simple one-liner with a major impact on btrfs
functionality being rejected *does* seem to say a lot about the
prospects of any btrfs-related work being accepted.
Putting myself in Neal's shoes, given my experience with that PR and
other attempts to help out with btrfs in anaconda, why would I invest
my time and effort to write another one when it seems extremely likely
it would be rejected?
There's an assumption here that when someone is asked to send a PR, it
will always be accepted. Enabling and/or fixing btrfs functionality in
anaconda is not a zero cost. There's also the issue that anaconda has
always aimed to not break systems. Does the project have the resources
to guarantee that and fix problems that show up? What might appear at
first as a "one line patch" comes with a lot of other assumptions and
expectations from users.
I think we at least owe it to people to be clear about whether there
is
any point in them investing time and effort *trying* to contribute to
btrfs support in anaconda, and if the answer is currently "no", whether
there would realistically be any prospect of there being any way to
change this.
I also think there are other perspectives that might at least
potentially be useful here. Right now we've mainly heard from a couple
of community folks who are very passionate about btrfs, and Red Hat
folks from anaconda/kernel development and RHEL management who
essentially see it as a burden that is not aligned with their
priorities. Is that all the perspectives we have to make a decision
with? I think we should at least talk to the Facebook team that
apparently uses btrfs on Fedora extensively about whether they'd be sad
to see installer btrfs support die and, if so, whether they'd perhaps
be interested in helping support it. And more broadly, community folks
on all the lists this is going to: are there more people who actually
are interested in this functionality and would be sad to see it go? If
btrfs isn't a part of Red Hat's product roadmaps but is important to
lots of folks in the wider Fedora community, maybe that's another
indicator we can use....or indeed, if it turns out not many folks
actually care.
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? 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).
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.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT