Hello,
I agree with Jan Lieskovsky.
I also vote for using milestones only for tracking releases
and labels to categorize issues and pull-requests.
This way, you can easily identify which release was the issue fixed in
and what long-term goals does it approach.
We use it the same way in OpenSCAP and I am very satisfied with that.
Regards
Jan Černý
Security Technologies | Red Hat, Inc.
----- Original Message -----
> From: "Martin Preisler" <mpreisle(a)redhat.com>
> To: "SCAP Security Guide"
<scap-security-guide(a)lists.fedorahosted.org>
> Cc: "Gabe Alford" <redhatrises(a)gmail.com>
> Sent: Monday, July 18, 2016 9:46:31 PM
> Subject: Re: [Proposal] Replace SSG feature milestones on GitHub with GH feature
labels -- any objections?
>
> ----- Original Message -----
> > From: "Jan Lieskovsky" <jlieskov(a)redhat.com>
> > To: "Gabe Alford" <redhatrises(a)gmail.com>
> > Cc: "SCAP Security Guide"
<scap-security-guide(a)lists.fedorahosted.org>
> > 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
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedo...
>
https://github.com/OpenSCAP/scap-security-guide/
>