If all tests don't pass, this doesn't mean it is so useless that it should be deleted, perhaps OK on some platforms?
Unfortunately that depends on your tests and what they mean. For example, Outcome has special workarounds for Visual Studio 2015 because it has a broken template variables implementation. If you try Outcome on Visual Studio 2017 RC, it blows up in a completely new way, both the special workaround AND the ISO C++ paths cause an ICE. Right now Outcome is unusable on VS 15 entirely (yay). So in this circumstance your tests failing don't mean a problem in your code, but rather the compiler. Without a human to judge that, you can't argue for deletion outright. You CAN argue that your library should not be supplied to users of that particular compiler version though.
But I've been keen on an 'accepted as candidate for Boost' distribution for many years, and I would still like to see this adopted. It would lead to better (and less acrimonious) reviews because we are not expecting perfection from day one. Too few people are reviewing 'real-life' usage. We need more users and that won't happen until we have a two-stage acceptance process.
Exactly my position on the matter. Too many reviews are made without use experience. Some libraries have been accepted that never should have been (Iostreams). Some libraries have been rejected that should never have been (too many to list).
On this can't we trust the author to move from his develop branch to master when he thinks fit?
Keep It Simple Sir?
My libraries have a three quality level branch system. Develop, or other experimental branches is where the commits happen. Master is what passes all the tests on the CIs. Stable is when I consider a particular master SHA as being of superb quality. I make use of github restricted push enforcement, so even I the owner cannot push any SHAs to master branch which did not pass all tests on another branch. It keeps me from being lazy :) The reason for the three quality levels is because of all the other automation scripting. You need a quality level in between stable and develop so all the projects dependent on you have something to test against in their CI passes in order to stamp their own master branches with updated git submodule SHAs. That flags when you've made an API breaking change in an upstream dependency BUT without breaking the downstream dependency which is still pinned to an older but still working earlier SHA. Also, when you fix the thing you broke, the downstream dependencies will automatically update themselves to your latest SHA, no manual effort needed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/