Re: Defining the future of the packager workflow in Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux