Hartmut Goebel <h.goe...@crazy-compilers.com> 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'.