Pre-Master checks (Was: Nightlies)

[Joachim Breitner]

Hi,

Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
> I want just to say thank you for thinking about this.  We badly need better nightly-builds for GHC, on a variety of platforms
> a) to identify regressions, preferably to the actually commit that
>    caused it, so Austin's big red message can go to the right person

I believe we can do better, so that Austin’s big red message does not
have to be written in the first place.

Here is what I have in mind, and I’ll volunteer to implement it if
people think it is a good idea and I get the resources/permissions:

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.

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.



-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/b30a3c80/attachment.sig>