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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
