On Tue, 2019-08-27 at 14:59 -0700, Adam Williamson wrote: > 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. Sorry but I have to react on this. It's killing me how many of you people here are telling Anaconda does not accept patches. That is really not true. We have smaller amount of contributions from community that is partially our fault because of a lack of documentation but mainly it's really hard to develop & test Anaconda and most users see it just once in a few years so it's not bothering them so much. I guess most of the installers are in the same situation. Please before any of you will tell again that Anaconda team is not accepting patches, please look on the last few years history. How many patches were "rejected" and how many were accepted. There are just a few patches which weren't accepted and basically only a few PR (I would even say the only one) for BTRFS. That is unfortunate but it's not all our contributions. Please stop saying all the time that Anaconda is not accepting contributions or that users doesn't have a chance to get the contributions in. > > 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. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
