| 1 |
Michael Mol wrote: |
| 2 |
> > I would argue that repoman and/or corresponding checks should be run |
| 3 |
> > by a CI system hooked up to the Gerrit instance that developers push to. |
| 4 |
> |
| 5 |
> I was thinking something similar, actually, except you'd need |
| 6 |
> something like this: |
| 7 |
> |
| 8 |
> 1. dev pushes to Gerrit |
| 9 |
> 2. Gerrit does processing |
| 10 |
> 3. Gerrit pushes to tree, if tests pass. |
| 11 |
|
| 12 |
This is exactly how Gerrit works and indeed what I expect also Gentoo |
| 13 |
to use. It's a very convenient workflow. |
| 14 |
|
| 15 |
|
| 16 |
> It would necessitate needing a separate mechanism to be able to undo |
| 17 |
> changes to tree that broke things Gerrit missed |
| 18 |
|
| 19 |
Gerrit can be told to revert any changeset. |
| 20 |
|
| 21 |
|
| 22 |
> It might also result in only being able to push one changeset at a |
| 23 |
> time, due to this scenario: |
| 24 |
|
| 25 |
The policy that Gerrit will use for adding commits in the output |
| 26 |
repository is configurable. |
| 27 |
|
| 28 |
One of the options is to require each commit to be a fast-forward. |
| 29 |
This means that every single commit blocks all other commits, but |
| 30 |
ensures that what is in the public repo is exactly what was tested. |
| 31 |
|
| 32 |
I personally find that merge policy unworkable. |
| 33 |
|
| 34 |
I tend to prefer cherry-pick, which means that commits pushed to |
| 35 |
Gerrit can be included in the output repo in any order, and that |
| 36 |
there is a risk for a merge conflict when Gerrit tries to pick the |
| 37 |
commit. It also means that there is a risk of false test positives, |
| 38 |
when the output repo has changed enough while the new commit was |
| 39 |
being tested to cause the new commit to break something. |
| 40 |
|
| 41 |
I personally find that merge policy the most practical, and |
| 42 |
experience from a few projects shows that the number of actual |
| 43 |
nontrivial problems is low if not zero. |
| 44 |
|
| 45 |
|
| 46 |
> git's email features to email diffs |
| 47 |
|
| 48 |
Nono, Gerrit does all of this already. Look into the documentation |
| 49 |
and/or set up an installation to play around with. |
| 50 |
|
| 51 |
|
| 52 |
Patrick Lauer wrote: |
| 53 |
> > I would argue that repoman and/or corresponding checks should be run |
| 54 |
> > by a CI system hooked up to the Gerrit instance that developers push to. |
| 55 |
> |
| 56 |
> So, let me get this straight ... |
| 57 |
> |
| 58 |
> $now: Developer A makes a change to automake |
| 59 |
> $now+10min: Change is pushed to CI |
| 60 |
|
| 61 |
What are the 10 minutes? |
| 62 |
|
| 63 |
|
| 64 |
> $now + 2 weeks: Initial testrun done, 734 potential issues found |
| 65 |
> (and 2 weeks is a pretty generous optimistic estimate) |
| 66 |
|
| 67 |
I think you mean something else than I do with CI and testing. |
| 68 |
|
| 69 |
It obviously doesn't make sense to build a whole lot of stuff per-commit. |
| 70 |
|
| 71 |
|
| 72 |
> At least your idea is completely unrelated to reality and a waste of |
| 73 |
> developer's time and minds, but thanks for bringing up something |
| 74 |
> completely silly again. |
| 75 |
|
| 76 |
You are behaving like an asshole. Please consider that what I |
| 77 |
contribute might be useful for Gentoo, and that if you have a |
| 78 |
different impression perhaps you have misunderstood something |
| 79 |
and can politely ask me to clarify if I really intend what you |
| 80 |
have interpreted. Thanks! |
| 81 |
|
| 82 |
|
| 83 |
//Peter |
Archives