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@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org