Pre-Master checks (Was: Nightlies)

Richard Eisenberg eir at
Tue Feb 4 14:42:32 UTC 2014


I, for one, would probably submit more bugfix patches with this structure in place. I take validating seriously, but my daily schedule often involves switching machines and tasks, and once I press "validate", it's often hours before I actually look at the results... by which time, some other commit may have come through. My need (real or perceived) for an uninterrupted chunk of time to make a patch stops me from doing them, sometimes.

With Joachim's structure, I could spend a half hour doing a quick patch (especially comments!) and push and move on.

Please do it! :)


PS: Transparency in the git redirects would be nice, of course, but is in no way necessary. We could I suppose add a "push" script to the repo that handles some of the overhead.

On Feb 4, 2014, at 4:41 AM, Joachim Breitner <mail at> wrote:

> 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
> (, 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
>  Homepage:
>  Jabber-ID: nomeata at
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list