Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 25, 2017, 00:56 UTC
Message-ID: <xmqqbmrlz4mm.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACBZZX7AmzFw-jVC_hd1t+qjK5jD485XD8g6U72p4RLoRD_kJA@mail.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Is getting the results of these builds time-critical? If not perhaps
> an acceptable solution would be to use a source repo that's
> time-delayed, e.g. 24hrs behind on average from Junio's git.git, and
> where commits are pushed in at some configurable trickle.

Because the tip of 'pu' is updated every day, but the tips of individual topics are not, the tip of the more stable side of integration branches are less often updated, I would think that an automated procedure (whether it is Travis or Dscho's Windows thing) that is most efficient for us would:

 - treat updates to 'maint', 'master' and 'next' as they do right
   now;

 - use update to 'pu' as a mere "trigger" and not test 'pu' as an
   aggregate as it is not very interesting (merges near the tip may
   be merging known-broken topics, like yesterday's pushout).

And arrange 'pu' update to trigger a procedure like this:

 - Grab the list of merge commits beyond what matches 'next':

   $ git rev-list --first-parent '^pu^{/^### match next}' pu

 - For each of these merges:

   - If its second parent (i.e. the tip of a topic) was already
     tested with the current 'master', do not bother testing it
     again;

   - Otherwise, call its second parent "it" in the below:

     - Create a merge of it (and nothing else) on top of 'master',
       and test it.  Each topic is intended to be able to graduate
       without other topics in 'pu', so this will catch potential
       breakage early and help blocking a broken topic from getting
       merged to 'master'.

     - When the above fails, test it in isolation to see if it
       itself is broken.  If this succeeds, we may have discovered
       unintended interactions between the topic and other topics
       already in 'master'.  Or the topic itself may already been
       broken.

     - In either case, record the test result so that the same tip
       of the topic would not have to be tested again, merely
       because the tip of 'pu' got updated next day due to updates
       in other topics.

We can s/master/next/ in the above description (I am undecided on pros-and-cons between using 'master' and 'next').