On 04/24/2013 07:21 AM, Peter Stuge wrote:
> Jeroen Roovers wrote:
>> Er, you can't be seriously suggesting we will drop repoman checks
>> with the migration to git? I don't see how that would benefit anyone.
> 
> I would argue that repoman and/or corresponding checks should be run
> by a CI system hooked up to the Gerrit instance that developers push to.
> 
> Anything else is IMO waste of developers' time and minds.

I was thinking something similar, actually, except you'd need something
like this:

1. dev pushes to Gerrit
2. Gerrit does processing
3. Gerrit pushes to tree, if tests pass.

It would necessitate needing a separate mechanism to be able to undo
changes to tree that broke things Gerrit missed, or it would necessitate
"undo" steps being pushed through Gerrit. Both have their disadvantages.

It might also result in only being able to push one changeset at a time,
due to this scenario:

1. Dev A pulls from tree
2. Dev A merges those changes with his local copy of tree
3. Dev A pushes to Gerrit
4. Gerrit begins tests on changeset A
5. Dev B pulls from tree (or perhaps he pulled earlier)
6. Gerrit is still testing changeset A
7. Dev B merges those changes with his local copy of tree
8. Gerrit finishes testing, pushes to tree
9. Dev B pushes to Gerrit
10. Gerrit runs tests on changeset B
11. Gerrit finishes tests, pushes to tree
13. Gerrit's push to tree fails, since tree with changeset A isn't in
changeset B's ancestry.

Though you might be able to get around that by using git's email
features to email diffs, allowing Gerrit to pipeline them (unless one
diff set fails to apply after another has been applied, of course).