On Thu, Oct 03, 2019 at 08:42:36PM +0200, Clement Verna wrote: > On Thu, Oct 3, 2019, 17:43 Jeremy Cline <jeremy@xxxxxxxxxx> wrote: > > > On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote: > > > On Wed, 2 Oct 2019 at 19:34, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> > > > 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. > My reaction was mostly to the concept of pushing everything as fast as possible to a "main branch". And yes, running some tests after the fact is better than running no tests ever (and has other purposes). However, finding problems *before* they happen is orders of magnitude more valuable than just merging, hoping, and testing afterwards to figure out where your hope strategy let you down. It should be encouraged by making the workflow the best choice for the developer, not by forcing them down that path. Furthermore, it's a compromise you don't have to make. Do what ever other CI system does: allow it to run on PRs *and* on whatever branches you want... Perhaps even continuously* on a branch or branches to ensure it integrates with components properly. *for some value of continuous _______________________________________________ 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
