[Qgis-psc] [QGIS-Developer] Direct push forbidden to master

[Jürgen E. Fischer]

Hi Denis,

On Fri, 08. Nov 2019 at 12:53:53 +0100, Denis Rouzaud wrote:
> > tests - kind of the reason I started with them - packages used to be a side effect
> > the tests also don't work completely on at least some non-travis platforms
> > - but as it's non-travis nobody seem to care - but it doesn't seem to
> > actually point to actual problems in the application - just to things in
> > the tests themselves.
 
> We could run the build and not the tests.

I tried appveyor already - ages ago - the build window wasn't even enough to
compile QGIS.  But we didn't buy extra cpu cycles back then.   Later Nyall also
tried, we even bought cycles, but that apparently still wasn't enough.

> Even asynchronously for windows if builds are too long.

We have that - nightly builds.

> That would be just a tad better than today, people would be aware of the
> broken build and the original author could fix it instead of you.
> I believe this is also a key factor here: you want direct push because you
> are fixing other's work because....it's not tested!

That's also in dash - but of course something that doesn't jump into your face
(but that's the same for travis - I think there used to be email notifications,
but not anymore).


> > I don't see a big problem with having the CI broken for a short time.  It's
> > master.
 
> I do. It's a waste of time for several people.

Doesn't any commit (including the merges of PRs) have the same effect on the
PRs?  So one direct successful commit just avoids the CI run it's skipped PR
would have caused?


> > And I think all the merge commits make a worse impression - esp. if
> > they are not squashed, than a temporary failing CI - and the former sticks
> > in the repository (as does a follow up commit for a breaking commit now an
> > then).
 
> Totally agreed. But let's maybe keep this for a followup discussion if we
> enforce PRs (way of merging).

 
> > I believe we are spend more time with the CI to prevent bugs than it ever
> > could take to fix them.
> 
> Yeah I do have the same feeling sometime. But at least we can identify some
> of the bugs before the release and can be reported independently.

And it helps with refactoring.


> > So I'm split - theoretically CI and tests are fine - practically they take
> > up a lot of time to make, maintain and run - maybe more then they are worth
> > - the sometimes (often?) breaks (unrelated to the actual commits) and
> > breaking direct commits are also an edge case and not the rule.  But save a
> > lot of time - and also prevent people from making parallel PRs on the same
> > issue.
 
> That's what we're trying to avoid here. If we lower breaking commits, we
> lower the chance than 2 devs are trying to fix master at the same time.

Pulling master to see if the issue is fixed is easier than going through a ton
of open PRs - esp. when they the issue is not covered by the CI to start with
(eg. I added a comment to a breaking commit, a fix was made, but it didn't
help).

I don't mind fixing QGIS and it doesn't matter who broke it - I just don't want
more hoops to jump through.


Jürgen

-- 
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20191108/ab806fbc/attachment.sig>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pflichtangaben
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20191108/ab806fbc/attachment.ksh>