Le ven. 8 nov. 2019 à 12:15, Jürgen E. Fischer <[email protected]> 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.
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
