* Unclear work- On 9/26/19 7:07 AM, Pierre-Yves Chibon wrote:
When we work on upstream projects, I think it's pretty standard now to always go via PRs, even for your own branch. So that tests are run, so that other member of the community can see, comment, review the change. What is so different in Fedora that we cannot move to this model? Is it a tooling issue? Is it something else?
I find the pull request work-flow rather awkward. Problems that come to mind. * Patch creators have to create a private (temporary) fork and branch. That seems like wasted effort. * Pull requests don't help maintainers all that much with review and testing. (I don't mean the commenting facilities, which are useful - I mean testing and evaluating a pull request is no easier than a plain patch.) * Poor integration between pull requests and issues. I think it would be better for a "pull request" to be a kind of issue that has an associated patch. That is what one did in the pre-GitHub world. All that is missing is a simple "accept patch" button added to a patch associated with an issue, which a maintainer can click when satisfied. * Related to the former: Unclear work-flow: Are you supposed to create an issue before you create a pull request? That is neither enforced or encouraged by GitHub or GitLab. Pull requests make sense for merging forks. I'm not sure they make sense for smaller changes. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/ _______________________________________________ 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
