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 <m...@joachim-breitner.de> wrote: > 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: m...@joachim-breitner.de > Homepage: http://www.joachim-breitner.de > Jabber-ID: nome...@joachim-breitner.de > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs