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...
> )
>
> * RHEL7 NIAP/USGCB Submission
> (
>
https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/U...
> )
>
> * NIST 800-53 identifiers assignment
> (
>
https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%...
> )
>
> * Unimplemented OVAL checks
> (
>
https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%...
> )
> * RHEL-6 USGCB Profile Review
> (
>
https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB...
> )
>
> * Draft RHEL 7 STIG
> (
>
https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%2...
> )
>
> 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