> On 22 Jan 2016, at 17:32, Michael Catanzaro <mcatanz...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
