proposals, status

[David B Anderson <davea at quasar dot engr dot sgi dot com>]

On spending some time with the status email today, here is my take.

It's a bit wordy, as by the time I got to the end, it had boiled
down to 4 things, 3 of them easy to deal with.
I can't take the time to make this shorter (paraphrasing
a famous author), so, well, it does run on.

Jason Merrill's Feb21 2000 
email titled
	991108.2 vtable element decoding
was really a new proposal, I'll call 000221.1
(ok I'm wrong, it is really 991108.2, but bear with me
for a while).


000221.1, could be created using
Jason's email. This is a vtable encoding proposal,
and represents a description of what gcc has implemented.

001213.1 should be created from
Ron's email of Dec 13 2000 "PROPOSAL for a default location attribute"
as this is, in effect, a proposal for a dwarf space optimization
along the lines of what Compaq has found useful.
Again, representing something that does have an implementation.

It would appear we should take some action on 001130.1
as that cures an objection to the existing issue with location
lists and .debug_ranges.

One of the problems with 001130.1 is that it refers not to the
001130 draft, but to earlier proposals.
This makes the proposal difficult to relate to the draft.
I for one would appreciate a statement of the proposal
relating to the latest draft (draft 5).
(similarly for the others, read on)

Of the proposals mentioned above, only 001130.1
is really difficult to understand (because of the 
difficult-to-follow references), but all 3 of the proposals
mentioned here:
	 001130.1 001213.1 000221.1
(the latter two are designations of things that
should be proposals, but accidentally got lost in the shuffle IMO,
though 000221.1 is perhaps really 991108.2, see below).

But all three should really specify what they apply to.
None of them, as they stand, use the words from the draft
or mention section numbers. I find ambiguity here.

I agree with Ron, too, that
	991108.13
has been fully addressed by actions taken. Language
in the draft solves these problems. This can be rejected
or whatever as it's done, toast, complete, defunct.

991108.2 becomes a duplicate of 000221.1 or perhaps
the content of the proposed 000221.1 should be added
to 991108.2 and we act on 991108.2. Whichever way, there
seems to be only one proposal here.

That leaves

991026.3  Duplicate Dwarf data deletion
I've written about this, but  the new info here is
we have a volunteer, Ulrich Drepper, on the implementation front.
And Ron says he has some enabling ideas.
The problem is it's January 2001 already. Lets continue:  

If we can take action on all the other things, leaving
only 991026.3, we can then declare this doc
closed to new proposals and focus on 991026.3. 
Myself included, though I sure hope some good ideas
come from Ron and Ulrich.

Are there any other proposals we should be considering?
 	I don't see others on the web site.

I don't think we can quite reject proposals out of hand,
but I don't think we should be accepting new proposals
unless they fix a bug in the draft (putting a
stake in the sand here).

Basically I think all the above but 991026.3
can be acted on, and I think I favor all the proposals.

But I really think the proposal wordings need to reflect
the current draft as there is much room for ambiguity as
written.  
Full list:

	991026.3
	991108.2 (choosing this identity arbitrarily over 000221.1)
	001130.1 
	001213.1

are it, and the last 3, I suggest, are things that 
we can easily vote on *once the wording is changed
in the proposals to say what section and words to change 
in the draft*.
Indeed, if I understand them, I favor all of the last 3 above.

Again, leaving only 991026.3 and the issues like ISTO.

Looks to me like we're really really close  to done folks.
Have I missed something?


Mike has called the meeting and by golly  we have a call-in number and
a meeting place.

Call-in number: 650-933-7963
SGI, B41, Magellan Conference Room
Mountain View. 10:30 AM.

Corrections and Flames to:
davea@sgi.com