Thanks, Shawn.
----- Original Message -----
From: "Shawn Wells" <shawn(a)redhat.com>
To: scap-security-guide(a)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:
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.
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-...
* 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-...
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