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? 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
