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 <[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
