I have a few plans that might help with this: - Try to improve travis (which will only possible to some point, because it's not hydra) ; - Have a bot post on each pull request the list of attributes touched by the PR, encouraging people to try to build them all (and improve nox-review to make it easier); - Prepare a proposition to switch to a bot-driven workflow for the PR, in which a bot does the merging: this lets us choose any rule we want for the merging. For example, PR are merged into a specific branch after acceptation by a collaborator and passing some tests.
It all comes down to the firepower of hydra. Encouraging people to check the build themselves is just a way to distribute computations we don't have the power to do. I'd love to have enough computing power to establish a workflow in which every PR is checked before it's merged into master or, even better, every PR is checked as soon as it is created. Georges Dubus 2014-10-25 18:07 GMT+02:00 Michael Raskin <[email protected]>: > >We have 2 solution, either we stop the regressions when a pull request > >(PR) is made, or we stop it when the fire is in. The fireman role is > >hard to keep, and we should be verifying as much as possible at the PR > >time. Also, if we want to avoid firemans, we probably want to forbid > >pushing patches to the repository without having made a pull request > >at first. Which means, no more massive updates without checks. > > We need a PR fireman already… > > And Travis still has false-failure rates that eclipse the worst failures > of Hydra. > > >One other way, is to have an "inbound", and a "nightly" branch. Every > >day, we merge in "nightly", the last green-build of the "inbound" > >branch which got tested by Hydra. This way we do not have a strict > >policy for pushing to "inbound". The only policy being that nobody > >merge into "inbound" if it is broken. This is the model used by > >Mozilla. > > I guess we could keep more or less the same policy as for current master > («remember, some people try to use the master branch on their systems») > with this split. > > Maybe fireman work could be reduced to «it's OK to revert if it breaks > something on Hydra». > > > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
