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
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
