Pre-Master checks (Was: Nightlies)

[Richard Eisenberg]

Yay!

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! :)

Thanks!
Richard

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 joachim-breitner.de> 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
> (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
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs