Simon, you don't think like versioning new names could be created and gradually over time downstream users would adopt new names as they adopted new versions?
Greg Elin P: 917-304-3488 E: [email protected] Sent from my iPhone > On May 6, 2014, at 4:35 AM, Simon Lukasik <[email protected]> wrote: > > On 05/01/2014 08:31 PM, Shawn Wells wrote: >>>> >To express my subjective opinion I like the idea of the project to be >>>> >renamed to "OpenSCAP Security Guide". But wanted to know wider opinions >>>> >from the community on the potential translation. >>> I think it's not necessary to rename the projects themselves. However I am >>> all for promoting the OpenSCAP "umbrella" and cross linking the projects. >>> Renaming the projects would be very costly and confusing for existing >>> users. The benefits aren't worth it IMO. >>> >>> In my opinion scap-security-guide should stay as is because >>> openscap-security-guide implies a tool lock-in which is not the case. >> >> Jan, thank you for starting this conversation! I'm _*very*_ much in >> favor of a unified umbrella/naming. >> >> As sgrubb pointed out, OpenSCAP has classically been the interpreter. If >> we rename SSG to "OpenSCAP Security Guide," the name creates an >> impression the content would only work with OpenSCAP. For this reason, >> are you proposing we change the OpenSCAP interpreter as well? e.g.: >> >> OpenSCAP: A portfolio of open source SCAP utilities and content, which >> includes: >> * OpenSCAP Workbench: Used for tailoring content (formerally >> scap-workbench) >> * OpenSCAP Interpreter: A cross platform, open source SCAP >> interpreter) >> * OpenSCAP Content: An open source project delivering a >> large body of SCAP content. Used as upstream for such profiles as the >> STIG and C2S >> * OpenSCAP Anaconda Plugin: A project to integrate SCAP >> scanning into Linux provisioning >> * OpenSCAP Spacewalk Plugin: A project to integrate >> centralized SCAP scanning into the Spacewalk/Satellite system management >> software > > I like this idea. > > However, I am afraid we are not able to enforce openscap package rename > everywhere to ensure consistent look. OpenSCAP library is spread across to > many downstreams. That leads me to conclusion that perhaps we don't need to > rename the downstream packages. Perhaps, we can just leverage this idea to > better describe ecosystem to newcomers. > > -- > Simon Lukasik > Security Technologies > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
