On Thu, Aug 29, 2019 at 4:23 AM <jkonecny(a)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
> > > 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
> 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
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
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
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
Please stop saying all the time that Anaconda is not accepting
contributions or that users doesn't have a chance to get the
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
, 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
But something is wrong and it needs to be fixed.
真実はいつも一つ！/ Always, there's only one truth!