Can you recommend a way how to share more detailed release changelog information via GitHub web UI?
Hello folks,
in effort to create new SCAP Security Guide v0.1.20 release and mainly trying to provide more detailed Changelog information, that would be reachable online (yet before the actual tarball has been downloaded & expanded) has been investigating GitHub web UI possibilities for this purpose.
One approach how this could be implemented is to provide the Changelog information in the particular milestone's description. But the problem seems to be there isn't a direct link provided how such milestone's description could be referenced later.
Example content is visible at: 1) https://github.com/OpenSCAP/scap-security-guide/milestones
to get the list of milestones
2) then click the "(more)" pseudo link below "Version 0.1.20: USGCB profile remediation and kickstart support" milestone to see the actual description.
From what I have searched looks this "(more)" pseudo link is handled
by JavaScript (thus at the side of the client's browser) and it's not possible to use it for referential purposes.
The vision behind future SCAP Security Guide updates is to provide also more detailed Changelog information for each release, basically split into three sections:
* New Features:
This not so much detailed section would be dedicated to briefly list main new features expected to be provided in this release (like support of new products etc.)
* Enhancements:
Here list of enhancements would be detailed (IOW enhancements for existing products like new remediations or new OVAL checks).
* Bug fixes:
Here list of bug fixes would be described (which build failures / OVAL checks / remediations have been corrected in this release).
Given (after the short review so far) the GitHub's milestone's description doesn't seem to be providing functionality for this kind of "web Changelog" was thinking of creating new GitHub SCAP Security Guide wiki page for each of the new releases and detailing that information there.
But prior doing that wanted to check experiences of other people / other ideas / suggestions, how this could be implemented.
Comments / recommendations / experience / proposals welcome.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On 1/15/15 8:54 AM, Jan Lieskovsky wrote:
Hello folks,
in effort to create new SCAP Security Guide v0.1.20 release and mainly trying to provide more detailed Changelog information, that would be reachable online (yet before the actual tarball has been downloaded & expanded) has been investigating GitHub web UI possibilities for this purpose.
One approach how this could be implemented is to provide the Changelog information in the particular milestone's description. But the problem seems to be there isn't a direct link provided how such milestone's description could be referenced later.
Example content is visible at: 1)https://github.com/OpenSCAP/scap-security-guide/milestones
to get the list of milestones
- then click the "(more)" pseudo link below "Version 0.1.20: USGCB profile remediation and kickstart support" milestone to see the actual description.
From what I have searched looks this "(more)" pseudo link is handled by JavaScript (thus at the side of the client's browser) and it's not possible to use it for referential purposes.
The vision behind future SCAP Security Guide updates is to provide also more detailed Changelog information for each release, basically split into three sections:
- New Features:
This not so much detailed section would be dedicated to briefly list main new features expected to be provided in this release (like support of new products etc.)
- Enhancements:
Here list of enhancements would be detailed (IOW enhancements for existing products like new remediations or new OVAL checks).
- Bug fixes:
Here list of bug fixes would be described (which build failures / OVAL checks / remediations have been corrected in this release).
Given (after the short review so far) the GitHub's milestone's description doesn't seem to be providing functionality for this kind of "web Changelog" was thinking of creating new GitHub SCAP Security Guide wiki page for each of the new releases and detailing that information there.
But prior doing that wanted to check experiences of other people / other ideas / suggestions, how this could be implemented.
Comments / recommendations / experience / proposals welcome.
Between v0.1.19 and v0.1.20: https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.19...v0.1.20
v0.1.20 through current/MASTER: https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.20...master /(note: since nothing was committed since this morning, nothing will be here)/
Or from the CLI, you can do something like:
$ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20 1bb6240 - iankko : Merge pull request #382 from iankko/version_0.1.20 3de0fae - Jan Lieskovsky : Make new 0.1.20 release 2de0a05 - Martin Preisler : Merge pull request #381 from iankko/pam_faillock_deny_fix_oval 45792dd - Jan Lieskovsky : [shared] accounts_passwords_pam_faillock_deny OVAL check: a806cad - Jan Lieskovsky : [shared] Modify OVAL check for accounts_passwords_pam_faillock_deny rule to require exact setting from second ex 973ab2b - Martin Preisler : Merge pull request #378 from iankko/rhel6_audit_privileged_cmds 9066343 - Martin Preisler : Merge pull request #376 from iankko/rhel6_nodev_nonroot_partitions 4546de2 - Jan Lieskovsky : [BugFix] [RHEL/6] Fix remediation script for audit_rules_privileged_commands to properly handle also case when m e24a208 - Jan Lieskovsky : [RHEL/6] mount_option_nodev_nonroot_local_partitions remediation: * Add reboot required NOTE per Shawn's recomme 236cb35 - Shawn Wells : Merge pull request #377 from iankko/rhel7_mismatched_tag
If we enforce tagging PR's with labels, such as "feature" vs "bugfix" we can then query based upon that information as well.
Thanks, Shawn.
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, January 15, 2015 10:53:53 PM Subject: Re: Can you recommend a way how to share more detailed release changelog information via GitHub web UI?
On 1/15/15 8:54 AM, Jan Lieskovsky wrote:
Hello folks,
in effort to create new SCAP Security Guide v0.1.20 release and mainly trying to provide more detailed Changelog information, that would be reachable online (yet before the actual tarball has been downloaded & expanded) has been investigating GitHub web UI possibilities for this purpose.
One approach how this could be implemented is to provide the Changelog information in the particular milestone's description. But the problem seems to be there isn't a direct link provided how such milestone's description could be referenced later.
Example content is visible at:
- https://github.com/OpenSCAP/scap-security-guide/milestones to get the list
of milestones
- then click the "(more)" pseudo link below "Version 0.1.20: USGCB profile remediation and kickstart support" milestone to see the actual description.
From what I have searched looks this "(more)" pseudo link is handled by JavaScript (thus at the side of the client's browser) and it's not possible to use it for referential purposes.
The vision behind future SCAP Security Guide updates is to provide also more detailed Changelog information for each release, basically split into three sections:
- New Features:
This not so much detailed section would be dedicated to briefly list main new features expected to be provided in this release (like support of new products etc.)
- Enhancements:
Here list of enhancements would be detailed (IOW enhancements for existing products like new remediations or new OVAL checks).
- Bug fixes:
Here list of bug fixes would be described (which build failures / OVAL checks / remediations have been corrected in this release).
Given (after the short review so far) the GitHub's milestone's description doesn't seem to be providing functionality for this kind of "web Changelog" was thinking of creating new GitHub SCAP Security Guide wiki page for each of the new releases and detailing that information there.
But prior doing that wanted to check experiences of other people / other ideas / suggestions, how this could be implemented.
Comments / recommendations / experience / proposals welcome.
Between v0.1.19 and v0.1.20: https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.19...v0.1.20
v0.1.20 through current/MASTER: https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.20...master (note: since nothing was committed since this morning, nothing will be here)
(Since I am still exploring the possibilities of GitHub's project web UI), these are handy to be aware of.
Maybe better to describe the motivation behind these documents - I am searching for a way how to create text documents describing the release (to prepare release notes & purpose clarification / mission statement for the new release).
These additional data should provide answers to questions like: * what's the difference among these two releases. Why should I install the most recent one?
* creating more detailed changelog helps return to the release version after some time to see what was the progress, what were the features etc. While git commits are natural to developers, it might not be that straightforward for end users - they are mainly searching / interested if some concrete feature has been implemented / some concrete bug has been fixed, not interested that much in all of the related necessary patches, that were required to be applied with that change together for proper work.
* for the future features document - where are they tracked, is there a list, can I contribute to the list, can I contribute by voting if something will be fixed in prioritized way?
Having had look at the GitHub milestone's & wiki functionality, for now decided to: * milestones * for past releases to track just release highlits and provide full feature changelog on the dedicated wiki page (for example have a look at new content of: "Version 0.1.20: USGCB profile remediation and kickstart support" under "(more)" link
The full release changelog is then available here: [1] https://github.com/OpenSCAP/scap-security-guide/wiki/scap-security-guide-0.1...
* for future releases to track summary of new features, maybe feature tags and link to proposed feature page (for example have a look at new content of: "Version 0.1.21: RHEL-6 USGCB stabilization towards Tier IV" (again see the "(more)" link)
The full proposed features page is then available here: [2] https://github.com/OpenSCAP/scap-security-guide/wiki/SCAP-Security-Guide-0.1...
In the moment of new release the release engineer would freeze the new features page & create a release notes document for that release.
Hopefully this will be perceived as the proper step to increase the transparency across past & future SCAP Security Guide releases (end users able to quickly to find consumable diff what's got changed for past releases & also able to participate on future features).
Or from the CLI, you can do something like:
$ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20 1bb6240 - iankko : Merge pull request #382 from iankko/version_0.1.20 3de0fae - Jan Lieskovsky : Make new 0.1.20 release 2de0a05 - Martin Preisler : Merge pull request #381 from iankko/pam_faillock_deny_fix_oval 45792dd - Jan Lieskovsky : [shared] accounts_passwords_pam_faillock_deny OVAL check: a806cad - Jan Lieskovsky : [shared] Modify OVAL check for accounts_passwords_pam_faillock_deny rule to require exact setting from second ex 973ab2b - Martin Preisler : Merge pull request #378 from iankko/rhel6_audit_privileged_cmds 9066343 - Martin Preisler : Merge pull request #376 from iankko/rhel6_nodev_nonroot_partitions 4546de2 - Jan Lieskovsky : [BugFix] [RHEL/6] Fix remediation script for audit_rules_privileged_commands to properly handle also case when m e24a208 - Jan Lieskovsky : [RHEL/6] mount_option_nodev_nonroot_local_partitions remediation: * Add reboot required NOTE per Shawn's recomme 236cb35 - Shawn Wells : Merge pull request #377 from iankko/rhel7_mismatched_tag
If we enforce tagging PR's with labels, such as "feature" vs "bugfix" we can then query based upon that information as well.
Speaking about labels, would it make sense to break them into more fine-grained level yet (e.g. something like "OVAL check fix", "New remediation", "New OVAL", "New OVAL for RHEL/7", "New OVAL for Fedora", "Remediation fix", "Common bugfix" ... - covering issues not falling in some of the previous categories).
IMHO these could be helpful when creating such release notes page [1] for future releases (but on the other hand to keep them in reasonable count).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
$ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20
What about $ git shortlog HEAD...`git describe` which gives you the commits and number of commits by author?
IMHO these could be helpful when creating such release notes page [1] for future releases (but on the other hand to keep them in reasonable count).
Definitely want to keep them at reasonable count, but committers would need to make sure that the tags are correct for PRs/Issues (depending on how the project thinks how strict committers should be).
On Fri, Jan 16, 2015 at 2:26 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Thanks, Shawn.
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, January 15, 2015 10:53:53 PM Subject: Re: Can you recommend a way how to share more detailed release
changelog information via GitHub web UI?On 1/15/15 8:54 AM, Jan Lieskovsky wrote:
Hello folks,
in effort to create new SCAP Security Guide v0.1.20 release and mainly trying to provide more detailed Changelog information, that would be reachable online (yet before the actual tarball has been downloaded & expanded) has been investigating GitHub web UI possibilities for this purpose.
One approach how this could be implemented is to provide the Changelog information in the particular milestone's description. But the problem seems to be there isn't a direct link provided how such milestone's description could be referenced later.
Example content is visible at:
the list
of milestones
- then click the "(more)" pseudo link below "Version 0.1.20: USGCB profile remediation and kickstart support" milestone to see the actual description.
From what I have searched looks this "(more)" pseudo link is handled by JavaScript (thus at the side of the client's browser) and it's not possible to use it for referential purposes.
The vision behind future SCAP Security Guide updates is to provide also more detailed Changelog information for each release, basically split into three sections:
- New Features:
This not so much detailed section would be dedicated to briefly list main new features expected to be provided in this release (like support of new products etc.)
- Enhancements:
Here list of enhancements would be detailed (IOW enhancements for
existing
products like new remediations or new OVAL checks).
- Bug fixes:
Here list of bug fixes would be described (which build failures / OVAL checks / remediations have been corrected in this release).
Given (after the short review so far) the GitHub's milestone's
description
doesn't seem to be providing functionality for this kind of "web Changelog" was thinking of creating new GitHub SCAP Security Guide wiki page for each of the new releases and detailing that information there.
But prior doing that wanted to check experiences of other people / other ideas / suggestions, how this could be implemented.
Comments / recommendations / experience / proposals welcome.
Between v0.1.19 and v0.1.20:
https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.19...v0.1.20
v0.1.20 through current/MASTER: https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.20...master (note: since nothing was committed since this morning, nothing will be
here)
(Since I am still exploring the possibilities of GitHub's project web UI), these are handy to be aware of.
Maybe better to describe the motivation behind these documents - I am searching for a way how to create text documents describing the release (to prepare release notes & purpose clarification / mission statement for the new release).
These additional data should provide answers to questions like:
- what's the difference among these two releases. Why should I install the
most recent one?
- creating more detailed changelog helps return to the release version
after some time to see what was the progress, what were the features etc. While git commits are natural to developers, it might not be that straightforward for end users - they are mainly searching / interested if some concrete feature has been implemented / some concrete bug has been fixed, not interested that much in all of the related necessary patches, that were required to be applied with that change together for proper work.
- for the future features document - where are they tracked, is there a
list, can I contribute to the list, can I contribute by voting if something will be fixed in prioritized way?
Having had look at the GitHub milestone's & wiki functionality, for now decided to:
- milestones
- for past releases to track just release highlits and provide full
feature changelog on the dedicated wiki page (for example have a look at new content of: "Version 0.1.20: USGCB profile remediation and kickstart support" under "(more)" link
The full release changelog is then available here: [1] https://github.com/OpenSCAP/scap-security-guide/wiki/scap-security-guide-0.1...
- for future releases to track summary of new features, maybe feature
tags and link to proposed feature page (for example have a look at new content of: "Version 0.1.21: RHEL-6 USGCB stabilization towards Tier IV" (again see the "(more)" link)
The full proposed features page is then available here: [2] https://github.com/OpenSCAP/scap-security-guide/wiki/SCAP-Security-Guide-0.1...
In the moment of new release the release engineer would freeze the new features page & create a release notes document for that release.
Hopefully this will be perceived as the proper step to increase the transparency across past & future SCAP Security Guide releases (end users able to quickly to find consumable diff what's got changed for past releases & also able to participate on future features).
Or from the CLI, you can do something like:
$ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20 1bb6240 - iankko : Merge pull request #382 from iankko/version_0.1.20 3de0fae - Jan Lieskovsky : Make new 0.1.20 release 2de0a05 - Martin Preisler : Merge pull request #381 from iankko/pam_faillock_deny_fix_oval 45792dd - Jan Lieskovsky : [shared] accounts_passwords_pam_faillock_deny
OVAL
check: a806cad - Jan Lieskovsky : [shared] Modify OVAL check for accounts_passwords_pam_faillock_deny rule to require exact setting from second ex 973ab2b - Martin Preisler : Merge pull request #378 from iankko/rhel6_audit_privileged_cmds 9066343 - Martin Preisler : Merge pull request #376 from iankko/rhel6_nodev_nonroot_partitions 4546de2 - Jan Lieskovsky : [BugFix] [RHEL/6] Fix remediation script for audit_rules_privileged_commands to properly handle also case when m e24a208 - Jan Lieskovsky : [RHEL/6] mount_option_nodev_nonroot_local_partitions remediation: * Add reboot required NOTE per Shawn's recomme 236cb35 - Shawn Wells : Merge pull request #377 from iankko/rhel7_mismatched_tag
If we enforce tagging PR's with labels, such as "feature" vs "bugfix" we
can
then query based upon that information as well.
Speaking about labels, would it make sense to break them into more fine-grained level yet (e.g. something like "OVAL check fix", "New remediation", "New OVAL", "New OVAL for RHEL/7", "New OVAL for Fedora", "Remediation fix", "Common bugfix" ... - covering issues not falling in some of the previous categories).
IMHO these could be helpful when creating such release notes page [1] for future releases (but on the other hand to keep them in reasonable count).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide 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: Saturday, January 17, 2015 5:28:29 PM Subject: Re: Can you recommend a way how to share more detailed release changelog information via GitHub web UI?
$ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20
What about $ git shortlog HEAD...`git describe` which gives you the commits and number of commits by author?
Thanks.
IMHO these could be helpful when creating such release notes page [1] for future releases (but on the other hand to keep them in reasonable count).
Definitely want to keep them at reasonable count, but committers would need to make sure that the tags are correct for PRs/Issues (depending on how the project thinks how strict committers should be).
AFAICT to enforce proper PR labeling we have basically two possibilities (maybe there are more of them): * enforce proper labeling on git repository level via git hooks (I don't have experience with these), * or enforce proper labeling on the GitHub's PR level - from what I have briefly looked it's possible to define pull request template via JavaScript: [1] https://quickleft.com/blog/pull-request-template-bookmarklet/ [2] https://quickleft.com/blog/pull-request-templates-make-code-review-easier/
And when at these -- looks it's also possible to define set of checkboxes, e.g.: [3] https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments
So combining these two together we could: * prerequisite: Have a list of basic labels (e.g. "OVAL check fix", "New remediation" ...), * have a pull request template containing couple of questions (IOW introducing uniformity into to the form new review requests will have), * and have couple of the checkboxes in that template expected to be filed when filing new pull request. Based on those truly checked in ones, we could hopefully set corresponding labels automa{t,g}ically?
Not something I would be immediately hunting for, but looks a nice feature to have for the future.
Thanks && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Going even further & taking GitHub's JavaScript support / functionality, maybe it would be even possible each accepted pull request to create new entry in the Changelog / Release Notes itself.
On Fri, Jan 16, 2015 at 2:26 AM, Jan Lieskovsky < jlieskov@redhat.com > wrote:
Thanks, Shawn.
----- Original Message -----
From: "Shawn Wells" < shawn@redhat.com > To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, January 15, 2015 10:53:53 PM Subject: Re: Can you recommend a way how to share more detailed release changelog information via GitHub web UI?
On 1/15/15 8:54 AM, Jan Lieskovsky wrote:
Hello folks,
in effort to create new SCAP Security Guide v0.1.20 release and mainly trying to provide more detailed Changelog information, that would be reachable online (yet before the actual tarball has been downloaded & expanded) has been investigating GitHub web UI possibilities for this purpose.
One approach how this could be implemented is to provide the Changelog information in the particular milestone's description. But the problem seems to be there isn't a direct link provided how such milestone's description could be referenced later.
Example content is visible at:
list of milestones
- then click the "(more)" pseudo link below
"Version 0.1.20: USGCB profile remediation and kickstart support" milestone to see the actual description.
From what I have searched looks this "(more)" pseudo link is handled by JavaScript (thus at the side of the client's browser) and it's not possible to use it for referential purposes.
The vision behind future SCAP Security Guide updates is to provide also more detailed Changelog information for each release, basically split into three sections:
- New Features:
This not so much detailed section would be dedicated to briefly list main new features expected to be provided in this release (like support of new products etc.)
- Enhancements:
Here list of enhancements would be detailed (IOW enhancements for existing products like new remediations or new OVAL checks).
- Bug fixes:
Here list of bug fixes would be described (which build failures / OVAL checks / remediations have been corrected in this release).
Given (after the short review so far) the GitHub's milestone's description doesn't seem to be providing functionality for this kind of "web Changelog" was thinking of creating new GitHub SCAP Security Guide wiki page for each of the new releases and detailing that information there.
But prior doing that wanted to check experiences of other people / other ideas / suggestions, how this could be implemented.
Comments / recommendations / experience / proposals welcome.
Between v0.1.19 and v0.1.20: https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.19...v0.1.20
v0.1.20 through current/MASTER: https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.20...master (note: since nothing was committed since this morning, nothing will be here)
(Since I am still exploring the possibilities of GitHub's project web UI), these are handy to be aware of.
Maybe better to describe the motivation behind these documents - I am searching for a way how to create text documents describing the release (to prepare release notes & purpose clarification / mission statement for the new release).
These additional data should provide answers to questions like:
- what's the difference among these two releases. Why should I install the
most recent one?
- creating more detailed changelog helps return to the release version after
some time to see what was the progress, what were the features etc. While git commits are natural to developers, it might not be that straightforward for end users - they are mainly searching / interested if some concrete feature has been implemented / some concrete bug has been fixed, not interested that much in all of the related necessary patches, that were required to be applied with that change together for proper work.
- for the future features document - where are they tracked, is there a list,
can I contribute to the list, can I contribute by voting if something will be fixed in prioritized way?
Having had look at the GitHub milestone's & wiki functionality, for now decided to:
- milestones
- for past releases to track just release highlits and provide full feature
changelog on the dedicated wiki page (for example have a look at new content of: "Version 0.1.20: USGCB profile remediation and kickstart support" under "(more)" link
The full release changelog is then available here: [1] https://github.com/OpenSCAP/scap-security-guide/wiki/scap-security-guide-0.1...
- for future releases to track summary of new features, maybe feature tags
and link to proposed feature page (for example have a look at new content of: "Version 0.1.21: RHEL-6 USGCB stabilization towards Tier IV" (again see the "(more)" link)
The full proposed features page is then available here: [2] https://github.com/OpenSCAP/scap-security-guide/wiki/SCAP-Security-Guide-0.1...
In the moment of new release the release engineer would freeze the new features page & create a release notes document for that release.
Hopefully this will be perceived as the proper step to increase the transparency across past & future SCAP Security Guide releases (end users able to quickly to find consumable diff what's got changed for past releases & also able to participate on future features).
Or from the CLI, you can do something like:
$ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20 1bb6240 - iankko : Merge pull request #382 from iankko/version_0.1.20 3de0fae - Jan Lieskovsky : Make new 0.1.20 release 2de0a05 - Martin Preisler : Merge pull request #381 from iankko/pam_faillock_deny_fix_oval 45792dd - Jan Lieskovsky : [shared] accounts_passwords_pam_faillock_deny OVAL check: a806cad - Jan Lieskovsky : [shared] Modify OVAL check for accounts_passwords_pam_faillock_deny rule to require exact setting from second ex 973ab2b - Martin Preisler : Merge pull request #378 from iankko/rhel6_audit_privileged_cmds 9066343 - Martin Preisler : Merge pull request #376 from iankko/rhel6_nodev_nonroot_partitions 4546de2 - Jan Lieskovsky : [BugFix] [RHEL/6] Fix remediation script for audit_rules_privileged_commands to properly handle also case when m e24a208 - Jan Lieskovsky : [RHEL/6] mount_option_nodev_nonroot_local_partitions remediation: * Add reboot required NOTE per Shawn's recomme 236cb35 - Shawn Wells : Merge pull request #377 from iankko/rhel7_mismatched_tag
If we enforce tagging PR's with labels, such as "feature" vs "bugfix" we can then query based upon that information as well.
Speaking about labels, would it make sense to break them into more fine-grained level yet (e.g. something like "OVAL check fix", "New remediation", "New OVAL", "New OVAL for RHEL/7", "New OVAL for Fedora", "Remediation fix", "Common bugfix" ... - covering issues not falling in some of the previous categories).
IMHO these could be helpful when creating such release notes page [1] for future releases (but on the other hand to keep them in reasonable count).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Jan Lieskovsky -
Shawn Wells