Pre-Master checks (Was: Nightlies)

[Carter Schonwald]

one point in the design space (mind you one i'm not going to advocate) is
the testing / merging workflow that the Mozilla folks are doing for rust.
 Every patch / pull request gets tested by their build bot before merging.
Does make the commits on master look pretty mess / mergy though.

mind you its a bit tightly coupled to github, but some of the ideas *might*
be a good strawman.  Likewise, how does eg LLVM/Clang manage its
testing infrastructure?  How does GCC manage it?


On Tue, Feb 4, 2014 at 12:56 PM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

> I can see advantages here, similar to Richard.  I'm just a bit worried
> about keeping all those branches straight in my head.
>
> Who names all these temporary branches?  Does someone delete them so they
> don't accumulate and dominate the branch list?
>
> Would need careful documenting, so that new people know exactly what to do.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> | Joachim Breitner
> | Sent: 04 February 2014 09:42
> | To: ghc-devs at haskell.org
> | Subject: Re: Pre-Master checks (Was: Nightlies)
> |
> | 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140204/b60134f8/attachment.html>