<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 5/6/14, 4:35 AM, Simon Lukasik
      wrote:<br>
    </div>
    <blockquote cite="mid:53689EDD.5@fedoraproject.org" type="cite">On
      05/01/2014 08:31 PM, Shawn Wells wrote:
      <br>
      <blockquote type="cite" style="color: #000000;">
        <blockquote type="cite" style="color: #000000;">
          <blockquote type="cite" style="color: #000000;">&gt;To express
            my subjective opinion I like the idea of the project to be
            <br>
            &gt;renamed to "OpenSCAP Security Guide". But wanted to know
            wider opinions
            <br>
            &gt;from the community on the potential translation.
            <br>
          </blockquote>
          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.
          <br>
          <br>
          In my opinion scap-security-guide should stay as is because
          openscap-security-guide implies a tool lock-in which is not
          the case.
          <br>
        </blockquote>
        <br>
        Jan, thank you for starting this conversation! I'm _<b
          class="moz-txt-star"><span class="moz-txt-tag">*</span>very<span
            class="moz-txt-tag">*</span></b>_ much in
        <br>
        favor of a unified umbrella/naming.
        <br>
        <br>
        As sgrubb pointed out, OpenSCAP has classically been the
        interpreter. If
        <br>
        we rename SSG to "OpenSCAP Security Guide," the name creates an
        <br>
        impression the content would only work with OpenSCAP. For this
        reason,
        <br>
        are you proposing we change the OpenSCAP interpreter as well?
        e.g.:
        <br>
        <br>
        OpenSCAP: A portfolio of open source SCAP utilities and content,
        which
        <br>
        includes:
        <br>
                 * OpenSCAP Workbench:    Used for tailoring content
        (formerally
        <br>
        scap-workbench)
        <br>
                 * OpenSCAP Interpreter:    A cross platform, open
        source SCAP
        <br>
        interpreter)
        <br>
                 * OpenSCAP Content:        An open source project
        delivering a
        <br>
        large body of SCAP content. Used as upstream for such profiles
        as the
        <br>
        STIG and C2S
        <br>
                 * OpenSCAP Anaconda Plugin:     A project to integrate
        SCAP
        <br>
        scanning into Linux provisioning
        <br>
                 * OpenSCAP Spacewalk Plugin:    A project to integrate
        <br>
        centralized SCAP scanning into the Spacewalk/Satellite system
        management
        <br>
        software
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      I like this idea.
      <br>
      <br>
      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.
    </blockquote>
    <br>
    Having a 90% solution is better than none; I see no harm if the
    OpenSCAP library package remains an outlier. As Greg pointed out,
    the impact of any change could be made over time (e.g. perhaps
    RHEL7).<br>
    <br>
    Today downstream already follows the openscap-* naming scheme, e.g.
    from RHEL 6.5:<br>
    <blockquote type="cite"># yum search openscap<br>
      ...<br>
      firstaidkit-plugin-openscap.noarch : OpenSCAP plugin for
      FirstAidKit<br>
      openscap-devel.i686 : Development files for openscap<br>
      openscap-devel.x86_64 : Development files for openscap<br>
      openscap-engine-sce.x86_64 : Script Check Engine plug-in for
      OpenSCAP<br>
      openscap-engine-sce-devel.x86_64 : Development files for
      openscap-engine-sce<br>
      openscap-perl.x86_64 : Perl bindings for openscap<br>
      openscap-python.x86_64 : Python bindings for openscap<br>
      openscap-utils.x86_64 : Openscap utilities<br>
      openscap.i686 : Set of open source libraries enabling integration
      of the SCAP line of standards<br>
      openscap.x86_64 : Set of open source libraries enabling
      integration of the SCAP line of standards<br>
      openscap-content.x86_64 : SCAP content<br>
      openscap-content.noarch : SCAP content<br>
      openscap-extra-probes.x86_64 : SCAP probes</blockquote>
    <br>
    Formally changing "SCAP Workbench" to "OpenSCAP Workbench," or SSG
    to "OpenSCAP Content" seems acceptable.<br>
    <br>
    One catch is that RHEL already has a package "openscap-content."
    Perhaps we could absorb the name? Or would this cause issues?<br>
  </body>
</html>