On Thu, Aug 29, 2019 at 4:23 AM <jkone...@redhat.com> wrote: > > 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. >
I sat on this for a few days, as I wanted to cool down and think about how to reply to this. As of this moment, I have directly and indirectly contributed to both the Red Hat and SUSE installers, and yes it's definitely true that both installers have some of the worst interaction models for contributors I've ever seen. YaST's contribution model and process seems to be somewhat better, because their team has components being used by other people. Their libyui components are used by Fedora and Mageia for dnfdragora, and the rest of ManaTools in Mageia uses it too. The YaST control center is a cornerstone in the user experience in SUSE distributions, so there are contributors from their community who do work on the main YaST components. The Calamares installer stack has a pretty healthy community, but our community has an interesting aversion to all things Qt/KDE even though the installer works fine on Fedora... But the point I'm trying to make is there is no reason for Anaconda to be so difficult. Unfortunately, it is. > 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. > I also took the opportunity look back at over the last 400 merged pull requests by paging through GitHub. Now I don't exactly have firm numbers, but in the past 400 pull requests, I saw less than a dozen pull requests merged from non-RHers. Half of them were from Pat from the Scientific Linux team. One of them was a documentation fix from some person I don't recognize with no clear affiliation. If I page back *slightly more* then the next PR from a non Red Hatter that was merged was *mine* fixing Anaconda's package exclusion feature for kickstarts (which was nearly two years old when it was merged). Of the 42 currently open pull requests, 4 are from people I could clearly identify as not from Red Hatters. Of the ones that are from Red Hatters, 7 appear to not be from members of the Red Hat Installer team or the Red Hat Bootloader team as I know of them. The lag time to response *is* improving. It's gone down from years to months, with the most recent pull request getting a comment within a week, and then stalling out after that. So it may even improve to weeks! As Adam pointed out, there's literally no reason for me to attempt more sophisticated changes to Anaconda if a simple one-liner can't get merged. And I didn't even make that fix, I've just been trying to shepherd it in for over a year! I only gave up trying and focusing on other things when it became clear I'd be dogged with non-answers forever. > 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. > You guys brought it upon yourselves by having terrible documentation and contribution policies, unclear ownership or responsibilities of projects that are clearly related (pykickstart, which by the way guys, changed hands *again* and now is basically in a brand new black hole!), oh, and lets not forget the oh-so-joyous aspect of the CI that is forbidden to be accessed by non-Red Hatters. Honestly, I shouldn't have expected better. When I noticed that the Anaconda mailing lists never moved from the Red Hat lists to lists.fedorahosted.org, I should have realized that Red Hat wasn't treating it like a community project. Every dysfunctional RH/Fedora ecosystem project seems to have that as a common property. It's emblematic of the deeper problem that it's not treated as a project where the community is valued. OpenShift, Spacewalk, and Anaconda are all projects where I've suffered these problems. That's not to say RH projects not hosted on the Red Hat lists can't be dysfunctional too, but people seem to try to be better when they aren't. Maybe it's an attitude difference? A different approach to the project? I don't know. But something is wrong and it needs to be fixed. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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/kernel@lists.fedoraproject.org
