[cxx-abi-dev] A proposed proposal process for the Itanium ABI

[David Vandevoorde]

On Aug 23, 2012, at 8:02 PM, John McCall wrote:
[...]
> Here is our mission at a small scale:  we want to develop and document
> the consensus among all the C++ implementors who use the ABI.
> 
> Okay.  As we see it, there are three classes of changes we can make:
> 
> 1.  An editorial change can be anything from a grammar / wording fix to
> a minor clarification of intent.  The key here is that we feel that it's totally
> uncontroversial and settled.  We won't bother notifying the list when we
> make this kind of update, but if you're interested, you can sign up at
> github for commit notifications.


Okay.  (Though if you have to "clarify intent", maybe it wasn't all that settled.)


> 2.  A minor change might be a missing case (e.g. in the mangler) or any
> clarification which isn't obviously settled or uncontroversial.  For these,
> we will make a point of notifying the list when making any changes.


I assume that means _prior_ to making any changes?  I.e., you won't commit changes to the document until "we" (this mailing list) have had a chance to react?




> For missing cases in particular, we will make an effort to make sure that
> the change is consistent with what seems to be current practice.  If there's
> significant divergence, we will post to the list for guidance before pushing
> anything into the document.
> 
> I personally have access to many versions of clang, many versions of gcc,
> and an increasingly old version of EDG.  If you would like me to consider
> your implementation when drafting or editing proposals, you should email
> me to make sure I can test it. :)


(We'll be happy to get you our latest release.)


> 3.  A major change is anything with a serious and potentially pervasive
> impact on the ABI.  Given our mission, most such changes are likely
> ruled out;  however, I am counting in this category anything which
> amounts to a major policy statement.  For these issues, we will attempt
> to lead a conversation on the list and develop consensus, waiting at
> least two weeks from the initial proposal before making any changes
> to the live document.



I don't think a distinction between "minor" and "major" change is useful here.  

My preference would be for changes to be posted to this mailing list, and if you (Mark Markland and yourself, presumably) think there is consensus, you announce it will be committed unless someone raises an alarm within a short time (Mark Mitchell had a 2-week settlement policy in the past, which seemed just fine, but I'd have no objection to a 2-day policy either).




> Anyone with a suggestion (or better yet, a patch) can just email Matt or me
> or both, and we'll try to, without undue delay, either push it into the
> repository or forward it to this list for discussion, as we think is appropriate
> by the above rubric.


Unless the change it truly editorial, I think patches/suggestions should go through the mailing first in all cases.

> 
> If you disagree with an emerging consensus, or if you feel that a previous
> change was mistaken or unfortunate, it is your responsibility to speak up.
> This is an open process, and it's nobody's full-time job;  we're not going to
> conduct straw polls or ring doorbells.
> 
> On an individual note, I will try not to let my role as maintainer of a specific
> implementation interfere with my role as editor of the general document.
> I think I've demonstrated in the past a willingness to change clang when
> we were the odd ones out or otherwise in the wrong.  I hope that other
> implementors are willing to reciprocate.
> 
> With all that said, we have something of a queue to get through.  Let's treat
> this proposal itself as a major change;  if you have objections, please
> bring them up as soon as possible so that we can work something out
> in the next few weeks.  If we can all agree that this is a reasonable basic
> process, then we can get started.

See above.

	Daveed