On Thu, Oct 3, 2019, 17:43 Jeremy Cline <jer...@jcline.org> wrote: > On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote: > > On Wed, 2 Oct 2019 at 19:34, Matthew Miller <mat...@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. > - Jeremy > _______________________________________________ > 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 >
_______________________________________________ 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
