Structure Peeps Initial Ideas

[tzlaine]

Overall structure:

• Each subproject is independent, and uses the Beman template, and is tied to
  some package manager; the subprojects may have interdependencies

• Beman proper contains:

  • A list of packages considered to be within the Beman Project

  • Common infrastructure (reference to the package that contains the
    template/scripts that build the template)

• Subprojects:

• Get added when they have a paper number

• Get updated with a new revision (Git hash, package version, and Git tag
  "RN", where "RN" is the paper revision suffix); a script should be
  provided to do all the things in one step.

• Get removed when they are voted down by LEWG

• Are retained when they are merged into the IS, but only as long as they
  are within two standards of the current standardization effort (e.g. if
  C++29 is being worked on, the oldest subprojects will be C++23)

For now, all subprojects are pure additions; changes to existing std entities
(like std::string::contains) still need to be figured out.

Subproject structure:

The Beman template should include:

• /include
• /src (if applicable)
• /test
• /doc
• /paper
• CMakeLists.txt
• package dependency on GTest
• package dependency on doc toolchain (TBD)
• .github/workflows/* (includes at least one code coverage build)
• README.md (including badges for the tests and code coverage)

A subproject should put its implementation in beman::cppN, where N is 26, 29,
etc. The N is the targetted ship vehicle for that suproject's paper. For
each cppN namespace, a user will see "inline namespace cppN" when building in
C++N mode, and just "namespace cppN" otherwise. Subproject authors are
encouraged but not required to also back-fill compatability implementations
for cpp(N-3) and cpp(N-6) namespaces.

If a project does not make it into C++N, a Github ticket should be auto-opened
requesting that the code moved to cpp(N+3). If this does not happen by the
next Beman pre-meeting update, the subproject is removed from the Beman index,
without prejudice.

Beman Project workflow:

• Every meeting, the project's list of head-versions of all its subprojects
  is updated.

• Every new C++ standard, the notification, and possible removal, of all
  pending subprojects is done.

[tzlaine]

Submitters are expected to have tests for all the big three implementations. The exception to this is for library features that depend on language features that are not yet available. In that case, tests should cover all the implementations that provide that language support. Submitters are encouraged but not required to provide workarounds for the lack of support on the other major implementations.

[bretbrownjr]

@tzlaine What if the subdirectory is papers instead of paper in case there are more than one paper being implemented?

[steve-downey]

That also covers the case of presentation decks and such that end up as published Pnnnn artifacts that aren't the "main" paper for a project. Or for ancillary papers by the same authors.

[dietmarkuehl]

The proposal says "includes at least one code coverage build". I'm not a great github tooling person. The example doesn't seem to include a coverage workflow and/or badge, yet. What do I need to do to set up a workflow which produces a coverage badge?

[bretbrownjr]

I agree that it's a little early to require code coverage, though I agree it would be great to make that a consistent feature of Beman libraries.

I personally haven't done a lot of specifically open source tooling in this space yet. I expect it's typical to use a service like https://codecov.io, publishing a standard coverage report format (like cobertura XML) with an off-the-shelf GitHub action of some sort. Possibly GitHub itself has direct support for coverage analysis reporting as well?

I would recommend pulling coverage analysis out of requirements docs right now and moving it to an enhancement request. The first step being getting one repo (maybe the example one) wired up and demonstrated to be both useful enough and maintainable enough.

Also note that we'll want to qualify our requirements for coverage analysis either way. At least some proposals would reasonably include compile-time features, and as far as I am aware, there is limited tooling for analyzing coverage of things like consteval, bodies of concepts, constexpr conditionals, etc.