On Sat, May 4, 2013 at 8:52 PM, Nelson, Clark <clark.nelson_at_[hidden]>wrote:

> > > 2) At what point will we consider these names stable enough for
> > > compiler vendors to start providing them? Are we OK with compilers
> > > starting to define these today? (FWIW, I think this is fine.)
> >
> > This raises a good point: Versioning of the list. Currently, it's
> > just Clark's ideas, not coordinated with anyone. I'd like to see
> > at least an N-numbered paper and possibly a "letter ballot"
> > equivalent [i.e. a table of interested people with yes/no/abstain]
> > recorded on some wiki page, or a teleconference, to "ok" a given
> > version of the list. Remember that we can't change the names
> > going forward.
>
> I think this topic deserves a separate thread. We are blazing completely
> new ground.
>
> The usual product of an ISO effort is a standard or other document, which
> is produced by a well-understood process, and approved by a wide variety of
> national bodies, each of which has had a chance to review the document. The
> process and the approval give the document its credibility, and make people
> believe that it's good enough to follow.
>
> But we're not planning to push a document through that process, nor to get
> that approval. So how will our recommendations gain the credibility that
> will motivate people follow them?
>
> Personally, I believe our best chance of that will be to demonstrate that
> PL22.16 and WG21, the ultimate technical experts on C++ if you will,
> believe that they are worth following. In other words, we need to get an
> approval vote on our recommendations recorded in the minutes of a meeting.
> For the purpose of getting such a vote, the most straightforward thing
> would be to have our recommendations in an N-numbered document.
>
> I mentioned this idea in the meeting a couple of weeks ago. No one
> disagreed with me at the time, but we didn't actually stop and ask whether
> there was consensus on that point. Worse yet, the discussion also included
> talk of maintaining our recommendations as a live document on a wiki. And
> it's also not perfectly clear whether that idea achieved consensus, nor how
> to reconcile the two ideas if a majority actually like both of them. For
> example, if the wiki is updated frequently, exactly how might we keep track
> of exactly which parts were covered by a WG21 approval vote?
>

As a strawman, maintain the living document on github (I would suggest in
the cplusplus project, alongside the repository for the draft standard,
etc., to give the document more credibility and legitimacy), with a branch
for those parts which have been approved by WG21.

One of the interesting things about Jens' comments above is that, when he
> talks about something like a letter ballot, I can't be certain whether he's
> talking about polling SG10 or PL22.16/WG21. Both might be reasonable, at
> different steps of the process.
>
> But I will go ahead and say this: I was originally at least hoping to
> publish my table in a WG21 N-document in the post-meeting mailing. I didn't
> because I ran out of time, and because it seemed like it might be better to
> wait for that step until we had demonstrated consensus among SG10 members,
> at least.
>
> In any event, I think we have two posts to pass: first, consensus among
> SG10 members. Second, consensus within PL22.16/WG21. I would suggest that
> implementers should wait until at least the first one to commit to specific
> macro names.
>
> But if enough implementers go ahead with the names as soon as SG10 agrees
> on them, then I suppose WG21's approval will be moot: it will be a fait
> accompli.
>
> Clark
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>