On 10/4/19 3:17 PM, Björn Persson wrote:
Panu Matilainen wrote:
On 10/2/19 8:33 PM, Matthew Miller wrote:
On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
○ Every changes to dist-git is done via pull-requests
Erm, no thank you. Pull requests are a terrible workflow.
It's definitely the winning workflow in the open source world today,
particularly for smaller and drive-by contributions, which I think we'd
like to encourage.
It's an awesome workflow for those cases. Not so much when you are the
maintainer of said piece.
In the drive-by contributor role I've always found pull requests
unwieldy. I thought they were intended for frequent contributors or
project members, for whom the added clicking might be a small burden
compared to all the work they do for the project.
Perhaps pull requests are convenient for a maintainer who receives them
in large numbers – I've only ever received one pull request so I can't
judge – but I don't see how they would encourage drive-by contributions.
If you want to encourage drive-by contributions, then you should make
it easy to submit a patch without first registering an account, forking
a project and so on.
Oh, true. PR's are really only convenient for existing habitats of the
ecosystem. For Fedora this means existing Fedora packagers, but as for
GitHub, "everybody" is already there and the bar to entry is quite low.
For the better or worse. But the "embrace" effect of these, um, services
is such that those who do not want to join for one reason or another
will have a difficult time contributing.
For the truly drive-by contribution from "outside", there's no beating a
single patch sent to an email address for convenience. With the downside
that it traditionally lacks any means to track what happens to the
patch, if anything. OTOH it's a feature of that process, sometimes
patches could use the right to be forgotten too.
Mind you, if I had the choice, I'd pick the good ole patches-via-email
workflow over these "social programming" platforms any day. But it is
what it is, and the PR workflow is not without its benefits.
- Panu -
_______________________________________________
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
