On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote:
> On Wed, 2 Oct 2019 at 19:34, Matthew Miller <mattdm@fedoraproject.org>
> 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. And there _are_ real tracking and review benefits to
> > having everything go through that workflow.
> >
>
> > Do you have an alternative proposal?
> >
>
> Continuous Integration can be done without PRs (this is not easy in the
> open source world because you cannot grant commit access to every
> contributors, this is not a problem for us since only the package
> maintainers have commit access), in fact eXtrem Programming [0] is all
> about pushing as often and as fast as possible to the main branch in order
> to get early feedback. Instead of running the tests against a PR it is
> possible to run the tests against the commits in the main development
> branch. I believe that in our case knowing if a particular commit broke the
> branch is as valuable as knowing if the tests failed against a PR.
>
Yeah, no thanks. As someone who endlessly chasing breakages I can tell
you it is miserable. That approach sounds like an eXtremly good way for
folks to just walk away from the project.
We can have machines check for correctness with tests, why on earth
would you enforce that check *after* accepting changes?
I think that it would be better to know which commit messed up your branch than not (currently the case). Currently there is no concept of "accepting a change" for packages, since packagers are just pushing commits to branches. To me running tests after the push is a good compromise and I don't see how that would drive people out of the project compare to enforcing all changes to be made via PR.