On Fri, Jun 24, 2016 at 10:19 AM, Shawn Wells <shawn@redhat.com> wrote:


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.

I'd say that or we do a better job of moving tickets/PRs to the actual release Milestones. Or have separate branches associated
the respective Milestones and merge those branches into the master when the milestone is complete like a ton of other projects do.

Gabe