Re: Discussion: what would not blocking on btrfs look like?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux