Re: Continuous Builds in GNOME

On Fri, 2016-06-03 at 09:42 +0100, Emmanuele Bassi wrote:
Even if we magically got the resources (build machines, at least one
person working on the infrastructure side, volunteer work to improve
the tooling), the attitude of "my module is my fiefdom, if a build
breaks *you* fix it" has to change. GNOME has long since become an
interconnected, complex system, and it requires a level of oversight
that does not map with "a loosely coupled set of components", with
each one of them that may or may not build; may or may not pass
may or may not break other components; may or may not lead to a
bootable, usable system.

Based on the last time we discussed this, I'm pretty sure this view is
passionately-held by a very small minority of contributors. Yes it's a
social issue, but also a technical one with bearing on our ability to
onboard new contributors and the productivity of existing contributors.
I support a policy that all contributors may revert a patch on master
if it breaks Continuous, and I suspect the rest of release team would
as well, as we're tired of dealing with jhbuild issues on release day.
master should always be buildable.

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.

I would also like us to stop tagging modules in Continuous in general,
instead revert commits that introduce build breakage in the modules
themselves, and save tagging for very rare cases where reverts are not
appropriate. Of course, sometimes we may need a transition in which
master of some module is broken for a brief period while somebody is
actively working on fixing it (in a matter of hours, not days). Such
issues are reasonable if they're rare. But in general, everyone should
feel empowered to keep our modules building.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]