<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 8 nov. 2019 à 12:15, Jürgen E. Fischer <<a href="mailto:jef@norbit.de">jef@norbit.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Denis,<br>
<br>
On Fri, 08. Nov 2019 at 09:19:11 +0100, Denis Rouzaud wrote:<br>
> > > We have had the direct push forbidden to master for a bit of time and it<br>
> > > proved to be useful.<br>
<br>
> > When did we vote on this?<br>
<br>
> That is basically the goal of my initial mail, to know if and how we can<br>
> take a decision on this.<br>
<br>
If I have a veto, then I already put it out.<br></blockquote><div><br></div><div>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.</div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Including windows in the CI and making it required to complete before merging<br>
will make it even more painful than waiting for what we currently have for each<br>
small commit - and it already gets more lengthy the more tests are added. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And it will also require to fix all the tests that never have worked on windows<br>
(see cdash for the last 10 years or something - the nightlies run the tests -<br>
kind of the reason I started with them - packages used to be a side effect -<br>
the tests also don't work completely on at least some non-travis platforms -<br>
but as it's non-travis nobody seem to care - but it doesn't seem to actually<br>
point to actual problems in the application - just to things in the tests<br>
themselves.<br></blockquote><div><br></div><div>We could run the build and not the tests.</div><div>Even asynchronously for windows if builds are too long.</div><div>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.</div><div>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!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I don't see a big problem with having the CI broken for a short time.  It's<br>
master.  </blockquote><div><br></div><div>I do. It's a waste of time for several people.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And I think all the merge commits make a worse impression - esp. if<br>
they are not squashed, than a temporary failing CI - and the former sticks in<br>
the repository (as does a follow up commit for a breaking commit now an then).<br></blockquote><div><br></div><div>Totally agreed. But let's maybe keep this for a followup discussion if we enforce PRs (way of merging).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I believe we are spend more time with the CI to prevent bugs than it ever could<br>
take to fix them.<br></blockquote><div><br></div><div>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. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Anyway, odd that there were still includes missing - my local windows build<br>
finally finished with the change (including building server, tests - also<br>
including the oracle provider - which also was broken a number of times by<br>
commits that went through the CI), but I didn't do clean a rebuild - because<br>
then I would have missed the nightly build window (the builds are still<br>
underway BTW).<br>
<br>
But fortunately this time the nightly doesn't have to replace a working build<br>
that is crashing on start.  Although that was quickly fixes, it was followed up<br>
other build breaking changes so that that crashing package wasn't quickly<br>
replaces (all that by commits that actually went through the CI).<br>
<br>
So I'm split - theoretically CI and tests are fine - practically they take up a<br>
lot of time to make, maintain and run - maybe more then they are worse - the<br>
sometimes (often?) breaks (unrelated to the actual commits) and breaking direct<br>
commits are also an edge case and not the rule.  But save a lot of time - and<br>
also prevent people from making parallel PRs on the same issue.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If I a build fails, I pull and if the problem is still there I fix it.</blockquote><div><br></div><div><br></div></div></div>