Branching and rebuild scheduling strategy

[Ludovic Courtès]

Hartmut Goebel <address@hidden> skribis:

> Am 17.10.2016 um 22:14 schrieb Ludovic Courtès:
>> Once ‘core-updates’ is merged (hopefully in a few days), we could start
>> a ‘staging’ branch and put changes that require between ~300 and ~1200
>> rebuilds.  The idea would be to close the branch much more quickly than
>> core-updates (the changes should be less disruptive, with little chance
>> of breaking things.)
>
> This is a good idea, too.
>
> I meant some branch like "core-updates-next", as a staging branch for
> the next "core-updates" cycle, too. So if he core-updates are currently
> build, we most likely do not want to tough it. But we could already push
> some changes to core-updates next to get them off our todo-lists.
>
> But maybe this is just what you call "staging" branch :-)

Yes.  To summarize:

| name           | rebuilds       | merge frequency | type                      
    |
|----------------+----------------+-----------------+-------------------------------|
| core-updates   | > 1200         | 2.5 months      | possibly disruptive       
    |
| staging        | 300 < n < 1200 | 3 weeks         | non-disruptive            
    |
| master         | < 300          | n/a             | non-disruptive            
    |
| $TOPIC-updates | > 300          | when it's ready | topic-specific (e.g., 
Python) |

Of course this depends on the power of our build farm and on how
disciplined we are.  ;-)  That is, we should pay attention to the status
of these branches on Hydra, fix issues in a timely fashion, and merge
them as soon as they're almost entirely built.

What do people think?

Ludo'.