Re: Build sheriffs for GNOME

[Bastien Nocera <hadess hadess net>]

> On 22 Jan 2016, at 17:32, Michael Catanzaro <mcatanzaro gnome org> wrote:
>
> > On Sat, 2016-01-23 at 03:14 +0900, Tristan Van Berkom wrote:
> > I do not support the vague notion that a "sheriff" can come along and
> > revert an entire branch I've just landed which changes the API
> > contract
> > early enough in the release cycle for depending modules to catch on
> > and
> > adapt to.
>
> 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.
>
> In practice, I don't think this is very often an issue; usually it's
> just little things that break. The most recent example comparable to
> your scenario would be grilo-3.0. In such cases, it usually makes more
> sense to tag/branch the module that broke API for a bit, or to try
> fixing the build in the affected modules.

Huh. All the modules I knew about using grill were ported within a couple of hours, the change was announced 
and an older version of the API was available in a branch (again, listed in the announcement).

You're basically complaining that the Music maintainers didn't update jhbuild. Which I eventually did after 
porting the app.

There are certainly plenty of better examples than this one.

> Michael
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list