This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[OT] "open standards" in gcc feedback

Hi all,

I'm hoping to get the opinions from users/devs in general and hope you
can forgive my post.
To start I'm really annoyed over the past couple of years for what
claim to be open standards, but in fact are only pay-to-play or just a
facade for corporate agenda.

Things which imho disqualify a standard from being "open".
1) Must pay to participate in general/private discussions (no option
for free participation)
2) Conducts everything in secret
3) Private testsuites - Which are even forbidden from being opened by
peer pressure
4) Primarily backed by corporate interests (single entity or even
multiple working together)

If the only thing your "organization" provides publicly is a
specification - you are *not* an "open standard". I'd love for FSF or
some open source group to provide guidelines on this. (So that I know
I'm not alone in my opinion)
Some of these standards are not-bad and some are even "good" (great?)
in the technical sense.

Specific issue - hard feedback welcomed
The space of offload computing (aka GPGPU) is getting a lot of
attention. As it gets more attention - trying to move it from HPC
specific problems to general and even to a point where open source can
feel comfortable using it. Some people will jump around and start
saying "OpenCL", but shut-up and read above.

I'd love to help with the following (assuming nobody has nuked me yet)
I'd like to start a focus group (open mailing list) where we (me, you
and anyone) look at the available GPGPU technology which exists today
and start to create (yet another - I'm sooo super sorry) standard
which is truly open and suitable for open source developers and open
source projects to rely on.

The outcome would be
1) Meets needs of C++ developers (HPC/general)
2) Meets needs of Fortran developers ...
3) Publicly available open specification - provided in pdf, text and
latex format
4) Some clearly defined license about the standard (is it CC or what)
patents.. etc
5) Free access to all mailing lists - Nothing secret or behind closed
doors. (I don't know if everyone will have voice or voting rights by
default tbd on that)
6) Strive to work ***WITH*** existing real standards where possible
long term. (For example Fortran J3 and C++ standards group)
7) To be as target agnostic as possible (I'm all for target specific
optimizations if they can be exposed in a fair way)
8) Build something which doesn't just create a wrapper around
closed/proprietary tools

I'm hoping that the large and strong gcc developer community can understand.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]