----- Original Message -----
> From: "Gabe Alford" <[email protected]>
> To: "SCAP Security Guide" <[email protected]>
> Sent: Friday, June 24, 2016 6:41:11 PM
> Subject: Re: [Proposal] Replace SSG feature milestones on GitHub with GH 
> feature labels -- any objections?
> 
> On Fri, Jun 24, 2016 at 10:19 AM, Shawn Wells < [email protected] > 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?
> 

I think, labels are very versatile and I don't see any reason why don't use 
them in such
way.

> 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.

I am afraid, that making of many branches could bring quite problems after some 
larger
structure changes - complicated merging.

> 
> Gabe
> 
> --
> SCAP Security Guide mailing list
> [email protected]
> https://lists.fedorahosted.org/admin/lists/[email protected]
> https://github.com/OpenSCAP/scap-security-guide/

--
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