On Mon, 2018-04-02 at 22:06 -0500, Rene Rivera wrote:
> On Mon, Apr 2, 2018 at 2:08 PM, Titus Winters <titus_at_[hidden]> wrote:
>
> > At the recent evening session in Jacksonville, many many things were
> > brought up in the realm of "tooling." These ranged all across the spectrum
> > of engineering tools, from IDE support, dependency management / discovery,
> > distribution, refactoring, and a host of other things.
> >
> > On the fly, I tried to cobble those into a coherent goal for SG15 and the
> > committee to aim toward. It's currently phrased very much for the
> > committee audience
> >
>
> Which I think is our main mistake. We have to stop thinking in terms of the
> committee being the audience. When the real audience is are general, i.e.
> not dedicated well informed, C++ users.

Most members of the committee participate to represent their users, I
think; either directly (e.g., the National Labs), indirectly (if they
are representing an implementer, so users of that particular
implementation), or both. Tooling will likely be created by these
people (or the organizations or open-source communities they represent),
not the average C++ user. Thus, I think it's fine if we target the
committee as an audience -- we generally rely on the committee to serve
its users, so no change here.

> In 10 years, the committee should deliver to the C++ user community
> specifications that tool vendors can use to produce a cohesive tool and
> library ecosystem for the entire C++ community.

Tool vendors can already do that. Lots of vendors provide a toolchain
and accompanying tools that cover lots of what users need (e.g.,
consider any decent GNU/Linux distribution). There are also
specifications for the tool-internal layers (e.g., ELF, DWARF, ...),
they are just not the same across all platforms or toolchains.

> * Common reproducible and interchangeable building of C++ products.
> * Common interoperable package specifications.

These are vague technical goals (which we could disagree on instantly, I
suppose). I don't think they are a good way to define a mission
statement because they don't say what the users and use cases are that
SG15 should try to work towards. What we should aim for is helping
certain people with the things they want to do -- how we can achieve
that best through technical means or specifications (or whether we can
achieve that at all) is still up for discussion, I believe.