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" <[email protected]> > To: "SCAP Security Guide" <[email protected]> > Cc: "Gabe Alford" <[email protected]> > 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" <[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/ > -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
