Charalampos Stratakis <cstratak@xxxxxxxxxx> writes:
> Well it seems so. I mean I would get it to an extend if this wasn't a
> *PR*. But anyway yes a two-line diff apparently should be a patch and
> not a sed.
>
> Also according to the PR comments I'm "unwilling" to do that upstream.
That is not how that word is used - the full comment reads:
- You have not made these changes in a way that is helpful to the
ecosystem as a whole
- Once you had to figure out what files needed changed, you could
simply have submitted a patch - as is done normally. This would
have enabled me to apply it upstream if you were unwilling to
submit it yourself.
Fixed the correct way in d269b84
This is a review of your code. You have submitted code, and I, the
reviewer, have indicated how it could have been improved, and shown how
I would have preferred it by example. This is normal open source stuff.
Are you unwilling to submit upstream? I can't say, hence the
conditional. What I can say (since upstream is me) is that you didn't.
> I don't see how that behavior helps the ecosystem.
So I see it like this:
Our goal is to land changes upstream. This helps for two reasons: not
only is our maintenance burden lowered by not carrying things downstream
in Fedora unnecessarily, but also other users (including other distros!)
get to benefit from our work.
Broadly speaking, upstreams either want PRs on a github/pagure/gitlab
frontend, or patches on a mailing list. In either case, the format
requirements are the same: something they can directly feed into git-am
or git-pull. The more work a downstream maintainer has to do to
upstream something, the less likely they are to do it.
So, if you want a change to help the ecosystem as a whole, upstream
first. Barring that, lowest barrier to upstreaming.
Thanks,
--Robbie
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
