[Proposal] Replace SSG feature milestones on GitHub with GH feature labels -- any objections?
Hello folks,
so there are these SSG "feature milestones" on GitHub: * Infrastructure Enhancements and Fixes (https://github.com/OpenSCAP/scap-security-guide/milestones/Infrastructure%20...)
* RHEL7 NIAP/USGCB Submission (https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USGC...)
* NIST 800-53 identifiers assignment (https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20i...)
* Unimplemented OVAL checks (https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20O...)
* RHEL-6 USGCB Profile Review (https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%20...)
* Draft RHEL 7 STIG (https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207%...)
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?
Thank you && Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
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%20...)
RHEL7 NIAP/USGCB Submission (https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USGC...)
NIST 800-53 identifiers assignment (https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20i...)
Unimplemented OVAL checks (https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20O...)
RHEL-6 USGCB Profile Review (https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%20...)
Draft RHEL 7 STIG (https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207%...)
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.
On Fri, Jun 24, 2016 at 10:19 AM, Shawn Wells shawn@redhat.com 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%20... )
- RHEL7 NIAP/USGCB Submission (
https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USGC... )
- NIST 800-53 identifiers assignment (
https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20i... )
- Unimplemented OVAL checks (
https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20O... ) * RHEL-6 USGCB Profile Review ( https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%20... )
- Draft RHEL 7 STIG (
https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207%... )
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
----- Original Message -----
From: "Gabe Alford" redhatrises@gmail.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org 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 < shawn@redhat.com > 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%20... )
- RHEL7 NIAP/USGCB Submission
( https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USGC... )
- NIST 800-53 identifiers assignment
( https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20i... )
- Unimplemented OVAL checks
( https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20O... )
- RHEL-6 USGCB Profile Review
( https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%20... )
- Draft RHEL 7 STIG
( https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207%... )
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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
Hi Gabe,
----- Original Message -----
From: "Gabe Alford" redhatrises@gmail.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org 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 < shawn@redhat.com > 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%20... )
- RHEL7 NIAP/USGCB Submission
( https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USGC... )
- NIST 800-53 identifiers assignment
( https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20i... )
- Unimplemented OVAL checks
( https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20O... )
- RHEL-6 USGCB Profile Review
( https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%20... )
- Draft RHEL 7 STIG
( https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207%... )
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.
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.)
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.
-1 on this approach due to maintenance burden. Suppose 20 such branches (not that much crazy idea given the count of features / products we are enhancing in parallel right now). Who will maintain those branches to keep them updated and address the conflicts?
Another PoV -- suppose a month or two when we wouldn't do any other change, than just progressing with some of those current milestones (e.g. we would made couple of changes to "Missing OVALs" one, couple of changes to "RHEL-7 STIG" support one, and for example also to "RHEL-6 USGCB review" one). But none of them would be completed during that period. What should go into the release notes? (we couldn't mention the changes because the corresponding branches wouldn't be merged into master yet)
Thank you && Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Gabe
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
----- Original Message -----
From: "Jan Lieskovsky" jlieskov@redhat.com To: "Gabe Alford" redhatrises@gmail.com Cc: "SCAP Security Guide" scap-security-guide@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.
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@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Cc: "Gabe Alford" redhatrises@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@redhat.com To: "Gabe Alford" redhatrises@gmail.com Cc: "SCAP Security Guide" scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Jan Cerny -
Jan Lieskovsky -
Martin Preisler -
Shawn Wells -
Zbynek Moravec