Open Stack

On 05/31/2018 03:50 AM, Thierry Carrez wrote:
> Right... There might be a reasonable middle ground between "every 
> commit on master must be backward-compatible" and "rip out all 
> testing" that allows us to routinely revert broken feature commits (as 
> long as they don't cross a release boundary).
>
> To be fair, I'm pretty sure that's already the case: we did revert 
> feature commits on master in the past, therefore breaking backward 
> compatibility if someone started to use that feature right away. It's 
> the issue with implicit rules: everyone interprets them the way they 
> want... So I think that could use some explicit clarification.
>
> [ This tangent should probably gets its own thread to not disrupt the 
> no-nitpicking discussion ]
>
Just one last one on this, then I'm hoping this tangent ends.

I think what Thierry said is exactly what Dims and I were saying. I'm 
not sure how that turned into
the idea of supporting committing broken code. The point (at least mine) 
was just that we should
not have the mindset that HEAD~4 committed something that we realize was 
not right, so we
should not have the mindset that "someone might have deployed that 
broken behavior so we
need to make sure we don't break them." HEAD should always be 
deployable, just not treated like
an official release that needs to be maintained.