Re: [ Revised Proposal ] Continuous Builds in GNOME

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Wed, 2016-06-15 at 17:49 +0000, Sriram Ramkrishna wrote:
[...]
> I think with a couple of iteration we can work out an agreement.  :)

Hi Sri,

I can see you read through this diagonally, so I'll try a TL;DR version
below...

> So to wit, let me summarize your points:
>
> * Master is unstable and can be in unbuildable state until we apply a
> tag making it stable.

Basically what it is today, mostly always buildable modulo transitional
periods in times of API churn, and modulo some mistakes which may take
time to fix for maintainers in different timezones with dayjobs.

> * We have a 'integration' branch or something like that which is
> always in buildable state but lags behind master by some undetermined
> number of commits.

The integration branch as proposed does not lag behind except by
commits which break integration, in all other respects it is always
exactly master.

> I'm a little unclear what a maintainer's workflow is, and how can we
> ascertain that they push to this integration branch when there is no
> social policy in place to do so.  I mean some maintainers can
> completely ignore that if they wanted to.

Nobody ever pushes to 'integration' (at least not developers and
maintainers), and this is why I want some strict git hooks in place to
ensure that any pushes to the integration branch are immediately
rejected ('git push origin integration' shows you an error).

TL;DR version is basically:

  o Yes, this is going to take some actual work to implement, technical
    work, but not an astronomical amount, maybe a few weeks.

  o The integration branch of every module is continuously
    reconstructed based on that module's master branch.

    This must be an automated process, which runs perhaps every 10 min
    or so, updating integration branches of all modules whenever new
    commits are available on master.

    At first it wont be completely automated, it will require some
    human intervention to assist in maintaining the blacklist of
    broken commits (we have a problem to solve which is deciding
    which commits to blacklist in the cases of API churn).

    Ideally though, the buildbots should be able to reconstruct
    integration by performing many variants and deciding on the
    blacklist with least changes omitted.

  o Notifications are delivered, perhaps bugs filed, against commits
    in master which dont integrate properly into 'integration'

    No need for a grace period, when your commit to master breaks
    integration, it is omitted from integration and you get a bug
    report.

  o Default for jhbuild is 'integration' of everything, which is
    almost always buildable (in fact it could be made to be literally
    always buildable with a bit more effort, assuming some tries
    are performed by the build bots before constructing the integration
    branches).

    In terms of workflow this would mean people would always work
    against the integration branch, except that developers/maintainers
    of a given specific module would checkout a few modules as master.

    Commits only ever enter the history via regular master or stable
    branches.


Basic gist of the idea is like this.

Cheers,
    -Tristan