I believe in fixing my own regressions when it clear that my patch introduced them.
As one of "those" developers whom happen to be on that list which caused the domdoc test failure. The patch passed on all the test boxes when submitted, just the CI failed. A test in the patch just happen to highlight an issue in another part of wine.
It took a long time to track the issue down and understand what was going on. Unless there is a CI testbox we can test against (easily). There are going to have to slip through, as some patch fix more than they hurt.
Who's responsibility was it to fix? (MR pending, by the way).
Stopping future MR from being committed due to a CI failures, will just drive possible developers to other projects. It's one think to fix your own patch up, its another to find/fix a complete different issue (maybe related). This scenario can lead to frustration when you initial 2 line patch requires another 10 patches before it can be accepted. Many will give up, "To Hard basket" and the bug will live for another 10 years.
Reverting patches isn't the answer and will just cause more pain than it's worth. 1. Bugzilla tracking, fix in x, reverted in y, now broken again. (what nightmare are made of). 2. Will make read git commits log more confusing.
Other options to consider * Have regular, regression/test fixes only release? (every Quarter?) * Have the paid wine developers work on them? ( *ducks* for cover. )*
* There seems to be more and more paid wine developers appearing every week. So might be a short term solution to make it possible.
Regards Alistair.