Re: Enabling builddir != srcdir by default in jhbuild

[Sébastien Wilmet <swilmet gnome org>]

On Wed, Jun 01, 2016 at 01:12:08PM +0100, Emmanuele Bassi wrote:
> The same thing will happen if you have a master/master-stable split,
> because now people will commit to master, break it anyway, and nobody
> will look at 'master-stable' because it's a completely different
> workflow than what Git and various tools and organisations use.

I said that jhbuild would build master-stable by default. A developer
would use master only for a few modules, the modules he/she works on.

Currently, GContinuous builds and tests the set of the latest commits
pushed on master. It doesn't have the time to test thoroughly each
commit individually. So what I have in mind, is that when that set of
commits fails, GContinuous would do a binary search in the list of
commits sorted in chronological order, to determine which module to tag
(i.e. for which module, the master branch will not get merged into
master-stable). When a module is tagged, a mail is sent to the
maintainers listed in the doap file. And then GContinuous can continue
with the next set of commits coming from master, except that it uses
master-stable for the tagged modules.

The problem is that GContinuous takes currently a shortcut: it doesn't
rebuild everything AFAIK. It just rebuilds the modules where there are
new commits, and for the other modules it just runs the installed unit
tests, if there are any. But, a certain commit in module A might break
the _build_ in module B. But if module B is not rebuilt when there is
the new commit in module A, GContinuous will think that everything is
alright, but when there is a new commit in module B and GContinuous
tries to rebuild it, it will fail but at that point it is too late, if
we take all the master-stable branches it fails.

So, there could be a master-stable-next branch, and e.g. once a day a
complete build, test and whatnot is done on all the master-stable-next
branches to determine if they can become master-stable. :-)

To simplify things, untagging a module could be done manually. Although
it is possible to imagine an algo doing that automatically.

Yes, I don't plan to work on all of this, it's just random ideas. But I
think this would be necessary to achieve a continuous delivery in a more
automated way. Maybe it'll be implemented in Fedora one day, with the
Atomic Workstation project?

--
Sébastien