On Tue, May 31, 2016 at 05:04:41PM +0100, Emmanuele Bassi wrote: > On 31 May 2016 at 16:01, Sébastien Wilmet <[email protected]> wrote: > > If you want real continuous > > integration/delivery, a commit should be pushed on master only if it has > > the green light from GNOME Continuous. It's the only way to avoid > > chasing continuously developers breaking stuff. > > This is the role of a try server; the problem is that: > > a) we have many interacting components > b) we don't have the resources to set up and maintain a try server > running continuous > c) unless you have a very limited subset of developers being able to > push to master, people will push to master > > I mean: we have an automated tool for translations that pushes to > master by default — and does not have any validation system to prevent > pushing translations breaking the build. We don't even have automated > hooks to validate translations, and those are usually the obvious > culprit of build failures. > > A try server is not a simple thing to set up; and if the cost of > setting it up is non-negligible, it simply pales compared to the cost > of keeping it up. We can barely keep Continuous building as it is — > somebody would need to be funded full time just to keep it going for > each bug/feature/patch series that we'd want to test.
With master/master-stable, developers, translators etc continue to work exactly as before. But GContinuous would automatically sets master-stable to commits that work (from the GContinuous point of view). And jhbuild would pick up the master-stable branch by default. It doesn't need more servers, it needs development time. Currently GContinuous needs maintenance: tag modules manually to a previous commit, untag, etc etc. A lot of that manual work could be replaced by an automatic way. In the short term it needs more time to develop that, but in the longer term, it saves time and we would have something that works better. > I mean: I proposed to have build sheriffs ensuring that Continuous > keep building and I nearly got accused of killing the GNOME community > because I had the temerity of saying that the subset of GNOME > specified in the Continuous manifest should always build, at the cost > of reverting commits that break the build if the maintainer is not > responsive. With master/master-stable, no need to manually revert commits. If master-stable is blocked at a previous commit, when new commits arrive on master GContinuous would try again to see if the problem is solved. But the maintainers need a way to know whether the build failed on master. With the doap file, a mail can be sent to the maintainers. The problem doesn't need to be resolved ASAP, as long as the problem is fixed for the next release. Currently when a module fails in GContinuous, it's a bit the panic, the problem needs to be resolved ASAP, the maintainers need to be pinged on IRC, someone needs to tag the module in GContinuous, and in the meantime it is not guaranteed that GNOME (or a subset of it) can be built in jhbuild. With master/master-stable, it's a more relaxed atmosphere. -- Sébastien _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
