Previously, Martin Zimmerman wrote in qdn.public.qnxrtp.advocacy:
Previously, Chris Travis wrote in qdn.public.qnxrtp.advocacy:
we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*
Foolish, you’re only promoting the confusion with that.
the .neutrino. groups will no longer exist
More foolishness, Neutrino IS the product/OS, QNXRTP is just a distribution of
Neutrino. Unless QSSL plans on obliterating any/all Neutrino product recognition,
this is a foolish choice.
Well, having ‘neutrino’ leads to confusion between ‘qnxrtp’ and
‘neutrino’ (are they the same?). Not having it obliterates ‘neutrino’
recognition. Go figure…
My reccomendation:
qdn.public.qnx2
qdn.public.qnx4
qdn.public.news
qdn.public.test
qdn.public.qnxrtp.installation
qdn.public.qnxrtp.newuser
qdn.public.qnx-jobs . . . . . . . . replaces . . . qdn.public.qnxjobs
qdn.public.qnx4.porting . . . . . . replaces . . . qdn.public.porting
qdn.public.neutrino.porting . . . . replaces . . . qdn.public.porting
qdn.public.qnx4.photon . . . . . . replaces . . . qdn.public.photon
qdn.public.neutrino . . . . . . . . replaces . . . qdn.public.qnxrtp.os
qdn.public.neutrino.apps . . . . . replaces . . . qdn.public.qnxrtp.applications
qdn.public.neutrino.devtools . . . replaces . . . qdn.public.qnxrtp.devtools
qdn.public.neutrino.photon . . . . replaces . . . qdn.public.qnxrtp.photon
qdn.public.qnx-advocacy . . . . . . replaces . . . qdn.public.qnxrtp.advocacy
qdn.public.qnxrtp.beta . . . . . . replaces . . . qdn.public.qnxrealtimeplatform.beta
That is just as confusing. ‘neutrino.apps’ vs ‘qnxrtp.applications’,
you think that’s easy?
thanks for all of the feedback, we are listening > 
Yes, but not well enough. QSSL is still sending the message that
QNXRtP is an OS, which is not correct. QDN also suggests that the OS’s
are QNX2, QNX4, NTO, and QNXRTP, very misleading, and very incorrect.
If that was my decision, I’d use ‘neutrino’ (or ‘nto’) prefix with ‘rtp’ and ‘oem’
suffixes. That would indicate that they share same core but have different packaging.
Group lists under them should also reflect what people usually do with respective
distribution. It would also be consistent with hardware packaging tradition
(OEM and Retail versions).
So, after qdn.public. we should have:
qnx4 - read only groups with 1 message explaining what is QNX4
… (I skip QNX4 groups for clarity)
neutrino - read only groups with 1 message explaining what is Neutrino
neutrino.core - common OS runtime
neutrino.photon - common Photon
neutrino.advocacy - flames and general interest issues.
neutrino.newbies - just crying for help
neutrino.oem - read-only group with 1 message explaining what is OEM Neutrino
neutrino.oem.setup - Setup and hardware support
neutrino.oem.crossdev - Cross development (may have subgroups for platforms)
neutrino.oem.embedding - Embedding (may have subgroups for architectures)
neutrino.oem.misc - Doesn’t fit well anywhere or concerns many
neutrino.oem.faq - FAQ
neutrino.rtp - read-only group with 1 message explaining what is RTP
neutrino.rtp.install - Setup and hardware compatibility
neutrino.rtp.apps - Applications
neutrino.rtp.devel - Self-hosted devel tools
neutrino.rtp.misc - Doesn’t fit well anywhere or concerns many
neutrino.rtp.faq - FAQ
All ‘explanatory’ groups should tell what the respective product is, who it is
targeted for, how it is different from other products/distributions and why one
should use this or that. Sort of mini-FAQ.