* 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
p...@bothner.com http://per.bothner.com/
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
