Re: Continuous Builds in GNOME

[Sébastien Wilmet <swilmet gnome org>]

On Tue, Jun 07, 2016 at 05:24:21PM +0900, Tristan Van Berkom wrote:
> One approach might be a setup where we have an RC branch opened for
> integration of changes from master at the beginning of each cycle -
> this could be a sort of "soft master" that builds but might not be
> bleeding edge in every way, it could benefit new comers as they could
> still submit patches against the RC branch and it should at least
> successfully build all projects from scratch. Also it could benefit the
> release team inasmuch as we could have constant awareness of exactly
> how much of the bleeding edge currently integrates at a given time.
>
> I strongly disagree with holding project maintainers responsible for
> creating feature branches and burdening them with the duty of updating
> other modules not under their control, especially for reasons already
> outlined in [0], however perhaps a uniform 'integration' CI branch
> could be automated to a certain extent, as gnome-continuous currently
> blacklists not-building modules, it could instead be made to guess what
> changes break a build and recreate the integration branch without the
> said failing patch, performing tries with merges from master until
> something builds and integration can again include the new changes.
>
> This of course, requires real thought and engineering, but I wanted to
> at least offer some technical input, some starting point that could be
> explored - this wont be solved without real engineering, trial and
> error.

It's similar to the "master/master-stable-next/master-stable" branches
concept that I thought about in this previous sub-thread. See those two
mails:
https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg00002.html
https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg00008.html

It doesn't look like rocket science to me, and it would get us closer to
continuous delivery.

--
Sébastien