On 2/4/14, Carter Schonwald <[email protected]> wrote: > 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?
LLVM devs need to run 'make check' before committing to the repo. This runs 8000+ tests in about 30 seconds. Then there is the bot infrastructure at http://lab.llvm.org:8011/console , and who breaks a target is alerted by mail. But this applies to all committers whose changes entered into (slow) builds. It is not commit-exact, though better on the fast bots. Cheers, Gabor > > > On Tue, Feb 4, 2014 at 12:56 PM, Simon Peyton Jones > <[email protected]>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:[email protected]] On Behalf Of >> | Joachim Breitner >> | Sent: 04 February 2014 09:42 >> | To: [email protected] >> | 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: [email protected] >> | Homepage: http://www.joachim-breitner.de >> | Jabber-ID: [email protected] >> >> _______________________________________________ >> 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
