Re: Continuous Builds in GNOME

[Michael Catanzaro <mcatanzaro gnome org>]

Hi,

A revert is not supposed to be "punishment" in any way... rather,
consider it as assistance to make sure GNOME stays buildable. :) But if
you really don't like it and don't want other folks reverting your
commits when you're not around, we can create a list of maintainers who
don't want this; that way, on the rare occasions when something breaks,
we can branch your module in jhbuild and tag it in Continuous instead
of reverting your change. I think it's generally better to avoid
branching/tagging, so I'd encourage maintainers to just accept the
occasional revert now and then, but it's understandable if we won't all
agree on this.

On Mon, 2016-06-06 at 11:01 +0200, Milan Crha wrote:
> - a soname version bump can break dependant projects. Such change
>   should not be reverted, the dependencies should be rebuilt.

Right; incremental builds with jhbuild are not completely reliable, and
a soname bump is generally not a valid reason to revert a commit. But
if a clean build doesn't work, then we have a problem to be fixed.

> - a soname version bump with an API change can break dependant
>   projects. Such change should not be reverted, the dependencies
>   should be rebuilt and adapted to the change.

In this case, when the API change breaks something in core or gnome-
apps, then the module and its dependencies really need to be updated in
jhbuild at (approximately) the same time, so there's at most a small
window of time where jhbuild is broken. Of course it can take time to
port dependencies; in such cases, we can either (a) make the API change
on a side branch, port dependencies on side branches, and merge the
changes to master when all GNOME modules are ready; or (b) make the API
change on master, but branch the module in the jhbuild moduleset so
that other modules continue to build against the older version of the
module with the API change. Really, you can do whatever you want, so
long as you avoid breaking jhbuild or Continuous, please!

> - a change which can build, but causes regressions in runtime. Such
>   change should be reverted, right? But wait, you care only about
>   the build, not about runtime. Having a software buildable and
>   having the same software usable are two very different things.

Yeah, of course runtime bugs are problems, but not the problem we are
trying to solve here. :)

Hope that clarifies where I'm coming from.

Michael