Abstain on 1651 Reason: This was discussed explicitly at the time that $sformatf was created and was rejected. While that would normally be cause for me to reject this, I appreciate the user concern about having to modify widely used code and will thus abstain. I strongly dislike any suggestion that there are "legacy" issues at work as any "legacy" issue would be based on a single vendor's non-approved extensions. Although other vendor's may choose to mimic such extensions, I dislike that being used as the rationale to modify the LRM. Yes on 1791 but with the friendly amendment that "sscanff" be corrected to "sscanf" (one "f"). Yes on 2611 but with a comment (repeated from the meeting) that I do not believe the LRM describes the reality of vendor implementations due to various extensions/interpretations of the LRM. So as a pragmatic issue, I would advise readers to not take the port rules too seriously. It is clearly beyond the time allotted to attempt to come to real agreement among the vendors. Yes on 2720 but with a comment that if ballot issue 9 / Mantis 2663 is addressed then this will be resolved indirectly. Yes on the remainder. Gord Maidment, Matthew R wrote: > -You have until 8am PDT, Monday, May 11, 2009 to respond > -An issue passes if there are zero NO votes and half of the eligible > voters respond with a YES vote. > -If you vote NO on any issue, your vote must be accompanied by a reason. > The issue will then be up for discussion during a future conference call. > -Note: For some issues, the proposed action is captured in the bug note > (resolve as duplicate, already addressed, etc.). > > As of the May 04, 2009 meeting, the eligible voters are: > > Brad Pierce > Mark Hartoog > Dave Rich > Gordon Vreugdenhil > Stu Sutherland > Alex Gran > Heath Chambers > Tom Alsop > Francoise Martinolle > Cliff Cummings > Shalom Bresticker > Don Mills > Steven Sharp > > Proposals: 1651, 1791, 2501, 2568, 2611, 2674, 2681, 2721 > > > SVDB 1651 ___Yes ___No > http://www.eda.org/svdb/view.php?id=1651 > > SVDB 1791 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2791 > > SVDB 2501 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2501 > > SVDB 2568 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2568 > > SVDB 2593 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2593 > > SVDB 2611 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2611 > > SVDB 2674 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2674 > > SVDB 2678 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2678 > > SVDB 2681 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2681 > > SVDB 2721 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2721 > > The following Mantis items are proposed to be resolved as: > > "The committee read and considered this feedback. the committee believes it > is too broad for the scope of the draft to implement at this time but may > be considered for future revisions." > > SVDB 2580 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2580 > > SVDB 2669 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2669 > > SVDB 2671 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2671 > > SVDB 2673 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2673 > > SVDB 2679 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2679 > > SVDB 2684 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2684 > > SVDB 2686 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2686 > > SVDB 2687 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2687 > > SVDB 2688 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2688 > > SVDB 2689 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2689 > > SVDB 2690 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2690 > > SVDB 2691 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2691 > > SVDB 2697 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2697 > > SVDB 2720 ___Yes ___No > http://www.eda.org/svdb/view.php?id=2720 > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon May 4 14:30:11 2009
This archive was generated by hypermail 2.1.8 : Mon May 04 2009 - 14:30:55 PDT