----- Original Message -----
> From: "Jan Lieskovsky" <[email protected]>
> To: "Gabe Alford" <[email protected]>
> Cc: "SCAP Security Guide" <[email protected]>
> Sent: Wednesday, June 29, 2016 8:10:45 AM
> Subject: Re: [Proposal] Replace SSG feature milestones on GitHub with GH 
> feature labels -- any objections?
> 
> 
> [snip]
> 
> IMHO from the nature of e.g. "RHEL-7 STIG" milestone, the issue being
> it's very unlikely we will address them in timeframe of one release
> (1-2 months). This is not just due the scope of changes that need to be
> implemented, but also partly due to us depending on external 3rd parties
> when implementing such effort (e.g. some standard first formally
> needs to be finished, till we can implement it in SCAP). So often we
> can't ensure this effort will be finished in 1-2 months.
> 
> IMHO labels approach is better in this situations, since label can span
> across multiple releases. And having milestones corresponding just to
> numeric release numbers, will ensure each issue:
> * can be tracked down to belong to particular release (e.g. it was fixed
> in 0.1.18 or 0.1.27 release). Right now, additional steps are necessary
> to find out, in which specific release the issue got actually fixed
> (basically just by mapping the date where it got corrected),
> * the nature / point of the change will still be visible (e.g. by
>  having "RHEL-7 STIG" label it would be immediately clear this change
>  belongs to finish "RHEL-7 STIG" support effort etc.)

+1

Makes sense to me to use milestones to track what we have implemented in
a release and labels to categorize issues.

-- 
Martin Preisler
Identity Management and Platform Security | Red Hat, Inc.
--
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