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

[Denis Rouzaud]

Le ven. 8 nov. 2019 à 12:15, Jürgen E. Fischer <jef at norbit.de> a écrit :

> Hi Denis,
>
> On Fri, 08. Nov 2019 at 09:19:11 +0100, Denis Rouzaud wrote:
> > > > We have had the direct push forbidden to master for a bit of time
> and it
> > > > proved to be useful.
>
> > > When did we vote on this?
>
> > That is basically the goal of my initial mail, to know if and how we can
> > take a decision on this.
>
> If I have a veto, then I already put it out.
>

You do have specific concerns due to maintenance of windows builds and
releases, but I am quite confident that we can find a way which works for
all.

>
> Including windows in the CI and making it required to complete before
> merging
> will make it even more painful than waiting for what we currently have for
> each
> small commit - and it already gets more lengthy the more tests are added.


> And it will also require to fix all the tests that never have worked on
> windows
> (see cdash for the last 10 years or something - the nightlies run the
> 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.
Even asynchronously for windows if builds are too long.
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!


> 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.


> 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.

>
> Anyway, odd that there were still includes missing - my local windows build
> finally finished with the change (including building server, tests - also
> including the oracle provider - which also was broken a number of times by
> commits that went through the CI), but I didn't do clean a rebuild -
> because
> then I would have missed the nightly build window (the builds are still
> underway BTW).
>
> But fortunately this time the nightly doesn't have to replace a working
> build
> that is crashing on start.  Although that was quickly fixes, it was
> followed up
> other build breaking changes so that that crashing package wasn't quickly
> replaces (all that by commits that actually went through the CI).
>
> 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 worse -
> 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.

>
> If I a build fails, I pull and if the problem is still there I fix it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20191108/5df3bf45/attachment.html>