Re: Continuous Builds in GNOME

[Milan Crha <mcrha redhat com>]

On Mon, 2016-06-06 at 09:49 -0500, Michael Catanzaro wrote:
> A revert is not supposed to be "punishment" in any way... rather,
> consider it as assistance to make sure GNOME stays buildable. :)

        Hi,
maybe it's not supposed to be, but it is in my eyes. I try my best to
not break builds, I'm grateful when other folks let me know when the
builds are broken for them. Neither jhbuild catches everything [1],
which you seem to suggest. I broke build in general, not only in the
jhbuild, in the not so distant past, which was a shame and it was all
my fault. I'm sorry for that, though in that particular case the change
on the evolution-data-server side was correct, only the evolution build
broke, because it wasn't updated appropriately. The revert on the eds
side would not make any sense. It was correct, as I said. (API changed
in some way and I didn't realize that the evolution uses the API in a
way which breaks it. Just my fault.)

I do not fully understand why reverting in some random project (and
making sort of hostile environment) is easier than the current state,
when the same person "tags" what commit is supposed to be used in
Continuous in the jhbuild. You still need the person, the person cannot
be a monkey, it will think before doing anything (I mean, it's not a
mechanical job where one rule fits each case).

I appreciate how Emmanuele and others (are there any others?) handle
the situation right now. I do not want to add them more work, really
not. 

> we can create a list of maintainers who don't want this

Nah, that's one more place to look at and to forget about. That adds
work to those nice folk(s) whom take care of the Continuous.

> 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.
> ...

Right, it's unrealistic in some cases to land all of that at one time.
Side branches is a nice idea, but it won't work, because you do not
have any influence on the other project maintainers usually, thus even
a bugzilla requests can lurk there for a long time. Having a side
branch only means that the maintainers whom do not follow particular
mailing list will notice only later, rather than sooner.

There is a bug to make more structures in Camel GObject based [2], to
be able to introspect it in a much easier way and so on. That change
will not be only a simple API change, it'll break core Camel things,
everything what uses it. If you open the [2], then I listed affected
projects at the end of the comment #5. It counts 18 projects. Maybe
there are more. I do not think I'd be able to coordinate the change in
a side branch for all of them, I (we) will surely provide patches in
the bugzilla around the time of the change landing, then it'll be up to
the respective maintainers to pick or reject them. What will the
Continuous do during this "broken period" is something I do not know. I
only know that the change will be for good. Introspection support for
the Mail part is good, I believe. Trying to revert such change in the
eds would hurt very much, no doubt.

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

Heh, true, though the runtime bugs are more important. I believe.
I know, that's one reason why you want to have the jhbuild working, to
make it easier for the contributors to test and develop. Which is a
good thing for everyone.
        Bye,
        Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=766540
[2] https://bugzilla.gnome.org/show_bug.cgi?id=764065