[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Discussion: what would not blocking on btrfs look like?
- From: Adam Williamson <adamwill fedoraproject org>
- To: David Cantrell <dcantrell redhat com>, For testing and quality assurance of Fedora releases <test lists fedoraproject org>, Neal Gompa <ngompa13 gmail com>
- Cc: Discussion, Customization of the Red Hat Linux Installer <anaconda-devel-list redhat com>, kernel <kernel lists fedoraproject org>
- Subject: Re: Discussion: what would not blocking on btrfs look like?
- Date: Tue, 27 Aug 2019 14:59:48 -0700
On Tue, 2019-08-27 at 13:25 -0400, David Cantrell wrote:
> > 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.
No, that's not what I'm assuming, but if we (Red Hat) tell people that
it would be a good idea to send PRs, we should at least be
*potentially* willing to accept them. We should not be saying 'send
PRs' if there is no chance of them being accepted. And it would be
nicest if we gave people a roadmap: here are the specific things you
can do that would be acceptable to us as a way to continue including
btrfs handling in the installer.
Just as a for instance - if the anaconda team would find it acceptable
to maintain btrfs installer support if some person or some group came
up with a way to modularize filesystem support in the installer such
that that person or group could maintain it and the existing anaconda
devs would not have to worry about it (and perhaps even such that
images could easily be built with or without support for specific
filesystems), then we should tell people that that is the kind of work
we're looking for and would accept if it was done.
I know the folks on both sides here and I understand both their
frustrations: the anaconda team is trying to maintain a very large
project with very limited resources and very specific demands from the
people who write their paychecks, which is absolutely a difficult
position to be in. But also, the community folks here are trying their
best to contribute - not just to demand that the RH folks do stuff for
them, but actually to contribute - but feel like they are being given
no guidance at all as to what kind of contribution would actually be
welcomed or acceptable, they feel like the message is "just keep coming
up with stuff and we'll keep rejecting it until we see something we
like". I know it's a tough position for both sides, but I really hope
we can get somewhere more positive than here with it.
> 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.
But then why not think about whether those resources are available
outside just the people Red Hat pay to work on anaconda? If there are
other folks banging on our door and telling us they really want to work
on supporting btrfs, wouldn't it be cool to at least try and see how
that could work?
> 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?
I agree, but I also think this discussion is kind of an input to that
decision. I don't know that FESCo can simply make it in a vacuum.
> 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).
That's exactly the kind of thing that would be helpful to the
community, indeed. If everyone can agree on this, that gives them an
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
[Date Prev][Date Next] [Thread Prev][Thread Next]