On 6/24/16 12:16 PM, Jan Lieskovsky wrote:
Hello folks,

   so there are these SSG "feature milestones" on GitHub:
   * Infrastructure Enhancements and Fixes
     
(https://github.com/OpenSCAP/scap-security-guide/milestones/Infrastructure%20Enhancements%20and%20Fixes)

   * RHEL7 NIAP/USGCB Submission
     
(https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USGCB%20Submission)

   * NIST 800-53 identifiers assignment
     
(https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20identifiers%20assignment)

   * Unimplemented OVAL checks
     
(https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20OVAL%20checks)
* RHEL-6 USGCB Profile Review
     
(https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%20Profile%20Review)

   * Draft RHEL 7 STIG
     
(https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207%20STIG%20)

There are two issues with the current approach:
* they are updated very seldom -- basically only in moment new release is 
created,
* they don't allow to reference all issues fixed in one particular release -- 
when some
   change is made (let's suppose it's related with RHEL 7 STIG effort), the 
corresponding
   change is tagged with "Draft RHEL 7 STIG" milestone.

   But it also belongs to some specific release (suppose 0.1.30 in this case). 
Trying to obtain
   all changes finished in 0.1.30 release this change wouldn't be present 
there, because it has
   "Draft RHEL7 STIG" milestone instead of "0.1.30" one.

Therefore the proposal is to move this SSG feature milestones into GitHub 
labels instead.
This way it will be possible to have just numeric milestones (0.1.31, 0.1.32, 
...) and
assign labels to pull request (so we won't loose the information some change / 
PR is relevant
to "RHEL 7 STIG" effort). Simultaneously will be able truly to list all changes 
that have
been finished in particular release.

I can turn the feature milestones into feature labels. But prior to doing that
wanted to know if there are some concerns / objections against doing that?

None from my side. Makes all the sense in the world. Should make release notes much much easier to create.

--
Shawn Wells
Chief Security Strategist
U.S. Public Sector
[email protected] | 443.534.0130
--
SCAP Security Guide mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
https://github.com/OpenSCAP/scap-security-guide/

Reply via email to