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@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
