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 entry point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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
