RFC: Criteria for backing out patches

Hi all,

looks like the WWDC has been a nice success, but
it is over now and all devs are back to normal mode.

I have written up a very subjective blog post here

<http://heisenbug.blogspot.com/2010/06/my-grief-with-out-of-tree-code.html>

in which I ask for clarifications to the development
policy wrt. backing out of buildbot-proven patches
because of (unintended) breakage in external projects.

It mostly amounts to how devs can cooperate to advance
the fundamental status quo regarding code quality in the
framework (i.e. the LLVM libs) and its clients (e.g.
Apple's OpenGL stack).

As you see this is a somewhat nagging need in me and
I would love to converge towards a satisfying solution.

Cheers,

  Gabor

Hi Gabor,

I saw your post and completely agree with you. Your patch should go in based on its own merits, if there is out of tree code that breaks, it isn't your fault or problem.

-Chris

Hi Gabor, if a change you make breaks an out-of-tree project, then I reckon
the least that project can do is supply you with a testcase, or if that's not
possible at least interact with you to track down the source of the problem.
In the case of dragonegg this has happened a few times, for example one of
Evan's dagcombine changes broke the d-e bootstrap. IIRC, I reverted his
initial patch, which he later reapplied with some fixes, which eventually was
reverted again, reapplied with more fixes and so on - this went on for some
time while I worked on reducing a manageable testcase. I forget how it ended,
but the point I would like to make is that it all happened amicably, with both
Evan and I clearly interested in finding the root of the problem. When this is
the case, it probably doesn't matter much whether patches are backed out or not,
since progress is being made.

Ciao,

Duncan.