Pre-Master checks (Was: Nightlies)
eir at cis.upenn.edu
Tue Feb 4 14:42:32 UTC 2014
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! :)
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 <mail at joachim-breitner.de> wrote:
> 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:
> 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.
> * 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
> * 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.
> ¹ 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 at joachim-breitner.de
> Homepage: http://www.joachim-breitner.de
> Jabber-ID: nomeata at joachim-breitner.de
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs