Re: Build sheriffs for GNOME

[Alexandre Mazari <scaroo gmail com>]

Not being a gnome developer, what follows is just a report of what I
experienced in a continuous integration/delivery environments at
$BIGCORPs where HEADs always build together, test stay green and
developers are (hopefully) able to evolve the design and
implementation without much hindrance.

Some ingredients are fundamentals toward those goals:
pre-hitting-master build/tests, clever versioning/dependencies
expression and atomic cross-repo pushes.

Pre-hitting-master build/tests:
As Lasse Shuirmann proposed, pushes are made to one-shot "quarantine"
remotes|branches instead of master directly. A CI bot instance is
launched, rebuilding the whole modules set and executes all the tests
suits.
If everything's fine, the commit goes to master. Yay! Else the
committer is notified and try again.
+ master HEADs always build together.
+ the feedback loop for the developer is hopefully direct and fast
- lot of resources consumption
- patches to different repos cannot be applied at the same time and
some sequencing is mandatory.

Clever versioning:
Semver, that you already do, ensure that API breaks are clearly
expressed in version bumps. The point regarding API breakage is moot
for build dependencies: a client project expresses dep on (range of)
specific versions known to match the API they expect. The dependency
version is bumped once the appropriate porting work is done.

Atomic cross repositories pushes:
But actually, not all dependencies are build-time enforceable. DBus
APIs, DConf schemas, GIR symbols used by dynamic languages bindings
etc... are all mostly resolved at runtime. Breakages of those wont be
caught by autotools and the compiler. Ideally, those runtime
requirements should be stressed by extensive tests coverage (or even
better, a proper type-system :P) but does such a thing even exist?

Furthermore, sometime API clients must be updated at the same time as
the API provider. If the API breakage is required to fix a critical
bug or security issue.

In such case, API producers and consumers *must* be updated at the
same time. As they often lay in different repositories, some tools
(gitlab, gerrit AFAIK) introduced the notion of atomic cross
repositories push/merge requests. Those are a set of patches to
different repositories that may only be applied or reverted together
as a unit.

All boils down to the following dichotomy: in a modular environment,
and for the sake of system health as a whole, is inter-modules
contracts enforcement the responsibility of the producers or the
consumers?

(As a side note, why would you ever commit a public API breakage if it
wasn't called in by, and validated with, at least one of your
consumers ? It sounds like breaking for the sake of breaking, IMHO)

Not sure how this all fits in current Gnome environment but keeping
HEADs buildable and green as an organization rule made my (and my
coworker's) daily duties a lot easier: devenv bootstrapping,
pinpointing regressions, not having to wait on others fixes and so
on... are very confortable.

On Fri, Jan 22, 2016 at 8:41 PM, Michael Catanzaro <mcatanzaro gnome org> wrote:
> On Fri, 2016-01-22 at 13:32 -0600, Michael Catanzaro wrote:
> > Ah, yeah, we should not be reverting entire large sequences of
> > commits... I agree that would be excessive. In cases like this, we
> > can
> > tag your module in Continuous and branch it in jhbuild, until other
> > modules have caught up with your API changes. Build sheriffs should
> > try
> > the least-disruptive option possible to get things fixed.
>
> We could also keep a list of maintainers who request that we not touch
> their modules directly, so we know to branch and tag your module when
> something breaks instead of committing to it directly. I suspect not
> many maintainers will opt-in to this, but you've made it clear there is
> demand!
>
> Michael
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
"If you open your mind too much, you brain will fall out"
Tim Minchin