Re: Build sheriffs for GNOME

["Jasper St. Pierre" <jstpierre mecheye net>]

It's more frequent than you might think.

In the past week, alone, we've had to tag glib, gnome-calculator,
e-d-s, gstreamer, and more, all because of broken builds. Take a look
at how busy gnome-continuous is as a project:
https://git.gnome.org/browse/gnome-continuous/log/

We currently have a team of people (usually Michael, Emmanuele, Colin
and Javier) who babysit gnome-continuous to file bugs for broken
components, tag the relevant component in GNOME Continuous, but it's
not a great workflow, in that it doesn't tend to keep master
buildable.

The first mail didn't really say how often build breakages in GNOME
actually happen -- they happen *a lot*.

On Fri, Jan 22, 2016 at 8:55 AM, Tristan Van Berkom
<tristan upstairslabs com> wrote:
> On Fri, 2016-01-22 at 10:37 -0600, Michael Catanzaro wrote:
> [...]
> > I really don't think it's a big deal to have a few reverts in the git
> > history. And anyway, reverts should be relatively rare, because build
> > breakage should be relatively rare.
> >
> > The master branch may be unstable, but that doesn't mean build
> > breakage
> > is ever acceptable. If your code is not buildable at all times in
> > Continuous, keep it on a *side branch* -- otherwise, tag your module
> > in
> > Continuous, branch it in jhbuild, and do whatever you want in master.
> > But as long as you have an official GNOME module, if it's not
> > branched
> > and tagged, master needs to build. This isn't the wild west.
>
> Of course, when you commit something and your *own* code does not
> compile, this is a very, very rare thing, rare enough to not be worth
> discussion I think, it that's happening, it's a problem.
>
> But it's common enough with many moving parts that the breakage is
> indeed intentional, in which case screwing with the history is only
> intrusive.
>
> > >     My interpretation of your proposal is that you would want to
> > > revert
> > >     this api break or behavioral change if it were found to break
> > > the
> > >     build (or the tests) of another module, during this unstable
> > >     development period.
> > >
> > >     This would obviously be wrong and would just be an obstacle to
> > >     progress in the cases where breakage is intentional and the
> > > only
> > >     correct solution is to have applications adapt to the new API
> > > or
> > >     behavior before the next stable release.
> >
> > It's a big problem that some modules break for days or weeks at a
> > time
> > during API transitions; this makes it very difficult for new
> > contributors to build and run GNOME, and it's inconvenient for
> > experienced contributors as well.
>
> This kind of breakage is just a fact of life, you cannot sweep it under
> the rug and pretend it does not exist.
>
> Sure, it's a barrier of entry for newcomers and an annoyance for
> experienced developers who realize the facts of life. But that's just
> the way it is, there is no reason to complain about it.
>
> Software development is difficult, integration is difficult when you
> have many moving parts that are in a development stage before being
> release ready.
>
> [...]
> > To be clear: if you've branched and tagged your module, then you do
> > whatever you want in master without hurting anyone else. But
> > otherwise,
> > master needs to be buildable.
>
> And to be doubly clear: the master branch is *not* what is advertised
> by upstream maintainers as stable, it is the bleeding edge, it can have
> churn, it may not always match up to other modules perfectly, other
> modules may have not yet adapted to the churn. Building master may be
> asking for trouble, again, this is just a fact of life if you are
> trying to integrate with all bleeding edge component in the middle of
> their development cycle, instead of what maintainers have published as
> stable.
>
> If you want something that you are sure will build, take the stable
> release tag and build that.
>
> Best,
>     -Tristan
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
  Jasper