Re: [boost] Review quality [ was stack trace review]

Subject: Re: [boost] Review quality [ was stack trace review]
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-01-02 11:36:14

> 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/