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
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@haskell.org] On Behalf Of | Joachim Breitner | Sent: 04 February 2014 09:42 | To: ghc-devs@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@joachim-breitner.de | Homepage: http://www.joachim-breitner.de | Jabber-ID: nomeata@joachim-breitner.de
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs