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