Re: Continuous Builds in GNOME

[Milan Crha <mcrha redhat com>]

On Fri, 2016-06-03 at 08:28 -0500, Michael Catanzaro wrote:
> I expect module maintainers to be understanding when reverts happen.
> It's not the end of the world; you can land your change again as soon
> as you figure out why it was broken. We can all live with a few
> revert commits in our git history. Your module can still be your
> fiefdom... just so long as it's still building with the rest of
> GNOME.

        Hi,
I'm not a fan of the random reverts from some 3rd party person whom
doesn't know the "bigger picture" of the project changes which can lead
to a win-win state, even the changes are that large that it's better
(for whatever reason) to split them into several commits, which not
necessarily follow in a short time. Such reverts would mean more work
for the maintainers, which is always a pita.

I hear here an argument that the maintainers claim that "it builds on
their machine" and they do not care of the other build environments.
Personally, I do not understand this statement, one (the maintainer)
should be willing to support his project home, appreciate that the
project can use the infrastructure and be tested in more places, which
is always a good thing.

The proposal about random reverts makes me feel that you want to flip
the positions. While I agree that the maintainers point of view is
broken, the position flip just means (for me): "the GNOME
infrastructure/jhbuild environment is the only good build environment
and if the maintainer breaks it, then the GNOME infrastructure team can
punish the maintainer if it needs to". Do you see how absurd it sounds?
The breakage should be dealt with in a cooperation manner, rather than
in a force manner. Of course, if the maintainer is not willing to
cooperate..., but I hope that's only a minority of the GNOME-hosted
projects (I do not know any numbers here) and definitely the core
project maintainers are all good, I believe, thus there might not be
any issue. The "bad" projects, if not from the core part, can be
skipped in the Continuous builds due to the lack of the interest from
the maintainers side.

There had been discussed also what can be reverted and what not.
If you recall:
- a soname version bump can break dependant projects. Such change
  should not be reverted, the dependencies should be rebuilt.
- 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.
- 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.

I suppose the GNOME build system runs some unit tests, if the module
provides such, but such tests are testing the new code, not the
regressions the change in the module can cause in another module which
had been/will be built against it.

Just my opinion on the matter.
        Bye,
        Milan