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