Re: [vhdl-200x] Call for Vote on Group Organization and PAR

My view on this is that even if the usage of VHDL is shrinking, it still
represents a significant user base and customer base. Even if no
enhancements are actually done it is important to have an active WG to take
care of maintenance and other issues that arise. In order for this to happen
under IEEE auspices it is necessary that there be an active PAR in place.
As a member of RevCom I have seen many standards that are in use by large
segments of industry suffer for lack of an active WG to take care of them.

The process that was followed, as outlined by Jim below, in the last
iteration seemed to work well. Rather than prejudge the outcome I would
like to see an active WG formed where the various constituencies of VHDL are
represented and they develop a thoughtful plan that is both realistic and
opportunistic in the sense of making improvement if and when they are
justified by a rational cost/benefit analysis. This seems to be what Jim is
proposing which is why I support the effort.

 thanks,
  Victor

On 12/20/10 3:22 PM, "Jim Lewis" <Jim@synthworks.com> wrote:

> Hi Stephen,
>> I asked Jim at the first meeting to use the SG to develop a marketing
>> requirements spec to use in selling the language revision. He declined.
>> It looks like Victor Berman is asking for something similar. Without
>> that information, the default decision for committing resources is to
>> decline.
>
> Technically all of the work to be done on the standard is up to
> WG, and not the study group. So whatever the study group
> decides, the WG could decide differently later. Hence, I am
> hesitant to have the study group make any statement about what
> the WG will decide later.
>
> However, Victor pointed out that I would probably be asked some
> clarification in the DASC meeting and rather than speak my mind,
> I thought it more important to summarize a group discussion.
>
> Looking forward, it is my desire that the WG is run in a similar
> fashion to the Accellera VHDL WG:
> 1) Develop and prioritize requirements.
> 2) Write proposals for implementation of requirements
> 3) Vote on proposals to make sure they address the requirements
> 4) Write LRM changes
>
> It would be appropriate if the vendors proactively reached
> out to their user community at some point in the process -
> either at step 1, step 3, or both - to make sure that the
> changes have value to their user community.
>
> Best Regards,
> Jim
>
>
>
>
>
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.