On 04/02/2014 01:41, Joachim Breitner wrote:
Proposal ~~~~~~~~
Nobody gets to push to master directly. Instead, every push to master is diverted¹ to a temporary branch "validating/<some id>". One of our servers detects the appearance of such a branch and will * check it out, * validate it, * if ok: check if master can still be fast-forward’ed to it, * if yes: push to master.
If it does not validate, or if master has changed in between, the branch will be moved to failed/<some id>, and a message is sent to the pushing developer², including a tail of the log and a link to the full log.
The system should try to rebase and re-validate automatically in this case. I think this is pretty important - otherwise pushes can fail for random reasons that are no fault of the developer. Actually I'd even go so far as to say that if the rebase succeeds without conflicts then the push should go ahead. Yes this can introduce bugs, but since a validate takes ~30 minutes at a certain rate of commits it becomes impossible to push anything if the tree must be validated and fast-forwarded to push. Also, bear in mind that since this stands between a developer and getting their changes in, it really must work, all the time. Be careful what you're signing up for :-) My feeling is that as a first step this system should be treated as a validation service: we don't force people to use it if they don't want to, so that we can see how well it works over time and developers can gradually migrate to using it. On that basis I'd be really happy to see it, and possibly to rely on it more over time. Cheers, Simon
Systems can fail, and maybe nothing validates anymore for reasons not easily fixable. For that case, a backdoor is available: Pushes to the branch "master-unchecked" will be moved to master, well, unchecked.
Benefits: * It is guaranteed that master has validated at least once somewhere. I.e. no need to ask on the mailing list “does master validate for you right now?” * It is now ok to do changes that are “obviously correct” (comment changes, removing dead code, code reformatting) without having to validate manually, which _saves developer time_ (our most precious resource).
Downsides: * When two commits are racing for master, one will be rejected for being a non-fast-forward commit. The user will then have to merge or rebase and try again. But: The same would be true if he was validating locally (unless he does not validate the merge/rebase, in which case we are again where we don’t want to be: Unvalidated versions in master.)
Is this something you would what, or could live with?
If it is technically feasible (given our hardware constraints, repository structure and git’s feature) is a different question, which needs to be discussed afterwards.
Greetings, Joachim
¹ Might not be possible transparently (http://stackoverflow.com/questions/21362833), but for the sake of argument and workflow design, assume it was. ² As an approximation: The committer of the latest patch.
PS: I’m also considering (but not pushing hard) for a stronger variant as follows. We do not need to discuss that now and should, if at all, start the with the proposal above. I’m just adding it to show where this is going ...
Stronger proposal ~~~~~~~~~~~~~~~~~
Every commit in master needs to be validated! I tend to make sure that all patches on my branch validate individually (git rebase -i -x "./validate" is a great tool here, you should use it! ). Contributors who do not want to go through that trouble should then use "git merge --squash" to produce a single commit from their branch.
This would make the git history more useful for things like bitsecting.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs