Pre-Master checks (Was: Nightlies)

[Joachim Breitner]

Hi,

Am Samstag, den 08.02.2014, 08:51 -0800 schrieb Simon Marlow:
> The system should try to rebase and re-validate automatically in this 
> case.  I think this is pretty important - otherwise pushes can fail for 
> random reasons that are no fault of the developer.
> 
> Actually I'd even go so far as to say that if the rebase succeeds 
> without conflicts then the push should go ahead.  Yes this can introduce 
> bugs, but since a validate takes ~30 minutes at a certain rate of 
> commits it becomes impossible to push anything if the tree must be 
> validated and fast-forwarded to push.

I’d actually prefer that behavior; I just didn’t want to put it in the
proposal because people might be much too scared by the prospect of
patches entering master that no human eye has seen so far – but after
someone suggested the same to me in private, and you now on the list, I
guess it would be a viable.

> Also, bear in mind that since this stands between a developer and 
> getting their changes in, it really must work, all the time.  Be careful 
> what you're signing up for :-)  My feeling is that as a first step this 
> system should be treated as a validation service: we don't force people 
> to use it if they don't want to, so that we can see how well it works 
> over time and developers can gradually migrate to using it.  On that 
> basis I'd be really happy to see it, and possibly to rely on it more 
> over time.

Correct: If I were to implement this (which has to wait for
http://hackage.haskell.org/trac/ghc/ticket/8545 to be reasonably
reliable) I’d set it up first as _alternative_ way to push, inviting
validate-lazy developers to use it instead of master. And if it works
great, we can consider making it mandatory (or at least the default).


So there seems to be a consensus here that this is a worthwhile feature.
Great!

Is there a roadmap for #8545?


Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140208/c9473944/attachment.sig>