Re: Continuous Builds in GNOME

[Tristan Van Berkom <tristan upstairslabs com>]

On Fri, 2016-06-03 at 01:53 +0000, Sriram Ramkrishna wrote:
> I found this discussion really fascinating and so I wanted to
> continue it, separately from Emmanuele's thread so that issue is
> resolved without bifurcating the discussion.
>
> My thoughts are that we really shouldn't be looking at something and
> say 'well, we can't do it we don't have the resources' especially
> when there is a clear return on investment.  I think this would be an
> interesting challenge and we should find a way to figure out how we
> can attract the talent, machines and money to do this.  After all, we
> have a foundation dedicated to supporting the development of GNOME.

Hi Sri,

I am not happy with how the previous discussion evolved. I think I
raised some technically valid points and historical insight, e.g. [0]
and [1] and I get the impression that those who are pushing this agenda
are not willing to digest the facts and converse constructively, but
lets re-examine this.

I am certainly not against continuous integration, but I think we need
to recognize first that we are in an extremely different position from
companies, organizations and projects which perform CI successfully -
this is not a solved problem that we can simply apply to GNOME as a
wider umbrella of various interconnected projects.

CI works very well where development is done in silo, all developers
are instantly reachable or replaceable, and all components are designed
to work in harmony for a very singular purpose. None of these
ingredients are present in the wider GNOME project.

So how can we improve things ? What technical approach can we take to
better leverage CI for the purpose of furthering the collective goals
of projects in GNOME ? Before we can even answer that question, we have
to ask also, what are the goals we want to achieve with CI, what do we
want to improve ?

I think this falls under 2 distinct categories:

  A.) Finding actual bugs and integration breakages early enough in the
      cycle to have a stable build come release time.

  B.) Making it easier for new comers to build and contribute to
      projects in GNOME.

I think first, we need to dispel the belief that the bleeding edge of
every module is going to build at all times - especially to new comers
who have the idea that they can build all of GNOME and it just doesn't
pan out, they get a bad experience because we advertise jhbuild of
master as something that should just work. We need to be more honest
here.

What we have currently with gnome-continous is already helpful for (A),
but can be improved. For (B) we don't have a solution right now, but
there may be some technical approaches to help solve (B).

One approach might be a setup where we have an RC branch opened for
integration of changes from master at the beginning of each cycle -
this could be a sort of "soft master" that builds but might not be
bleeding edge in every way, it could benefit new comers as they could
still submit patches against the RC branch and it should at least
successfully build all projects from scratch. Also it could benefit the
release team inasmuch as we could have constant awareness of exactly
how much of the bleeding edge currently integrates at a given time.

I strongly disagree with holding project maintainers responsible for
creating feature branches and burdening them with the duty of updating
other modules not under their control, especially for reasons already
outlined in [0], however perhaps a uniform 'integration' CI branch
could be automated to a certain extent, as gnome-continuous currently
blacklists not-building modules, it could instead be made to guess what
changes break a build and recreate the integration branch without the
said failing patch, performing tries with merges from master until
something builds and integration can again include the new changes.

This of course, requires real thought and engineering, but I wanted to
at least offer some technical input, some starting point that could be
explored - this wont be solved without real engineering, trial and
error.


One line of thinking I think we really need to distance ourselves from,
is the idea that the "social problem" of projects in GNOME is one that
needs itself to be fixed. Yes it is a problem, but rather a riddle or
puzzle to be solved. Lets embrace the community as it is and find a
technical solution that works *for* the community, not try to teach the
community that their goals should be more in line with what some
particular participants think.

I say this, because I sense there is some impatience coming from
participants who seem to hold the belief that a uniform and beautiful
desktop experience is the singular goal of all projects participating
in GNOME, while on the other hand, projects who have been solving real
problems and are targeting a much wider audience than just this suffer.
The result is that we begin to alienate smart and diligent developers
who have been long standing dedicated contributors, and we attract
young blood to write a (example) new clock applet that merely, looks
the way we want it to. We need to achieve the latter without
sacrificing the former and this is a social problem we have to address
as well.

Cheers,
    -Tristan

[0]:https://mail.gnome.org/archives/desktop-devel-list/2016-January/msg
00046.html
[1]:https://mail.gnome.org/archives/desktop-devel-list/2016-January/msg
00051.html