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

[John McCall]

On Aug 24, 2012, at 6:49 AM, David Vandevoorde wrote:
> 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.)

I'm thinking here of places where the intent is obvious — usually explicit —
in one portion of the document, but where the local wording is more obscure.
That sort of thing is inevitable in specs, and it's certainly present in ours.

>> 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 something that seems like an addition — like "how should we mangle
such-and-such" — yes, definitely.  I was hoping that we could use a shorter
review period for things that seemed minor, just to keep down the number
of different proposals in-flight.

Most of the uncontroversial minor changes that I have in mind are the
back-log changes:  everything we've talked about on the list in the last
few years which hasn't yet made it into the document.  I agree that it's
probably not worth calling these out as a special, more streamlined
process, though.

>> 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.)

Thank you.

>> 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).

That seems fair.   So, the process is:  for any non-editorial changes, we'll make
sure that it's sent out in advance.  At some, when consensus seems to have
developed (and for a lot of the back-log items, that will probably be
"as part of the same email"), Mark or I will announce that it'll be committed
after <concrete period of time> if there aren't any more objections.  The
period of time will vary according to how major we think the change is, but
it'll never be less than two days, and it'll be at least two full weeks if there's
been serious debate on the list (for back-log changes, this includes at the
initial time of proposal).  Furthermore, anyone can ask us to hold off while
they investigate and/or draft a response.

To make the lifetime of a proposal as clear as possible, we'll also signal the
list after committing anything non-editorial, and we'll try not to have more than
two proposals under discussion at once.

John.