On 5 June 2016 at 19:13, Kent Fredric <kentfred...@gmail.com> wrote: > On 6 June 2016 at 05:09, rindeal <dev.rind...@gmail.com> wrote: >> It is not, unless CI filters the broken commits in some miraculous >> way. With the current approach, both stable and master branch will >> contain the pollution of broken commits + their fixes, instead of >> having good commits only. > > > Doing that is of course, impossibly hard without having every > committer publish to their own branch, and having the "master" built > by *cherry* picking commit series that are "known good". > > Its doable, but the complexity it entails is just way more than is > suitable for the gentoo workflow, and is likely to create more > problems than it solves. > > The "no bad commits" requires there to be at last *some* branch > somewhere that is constantly not-fast-fowardwardable, and at least one > branch that serves as a synchronization point with strictly linear > history.
It's not hard at all. Developers have branches (personal, feature/bug specific, ...), before merging to master they do a rebase+force push, let the CI check it, and if it passes they're allowed to merge it. No cherry-picking involved. Master is then always clean and happy. I'm not sure how well it scales, but for the 100-150 commits/day the tree sees currently, it should be doable.
