----- Original Message -----
From: "Gabe Alford" <redhatrises(a)gmail.com>
To: "SCAP Security Guide" <scap-security-guide(a)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(a)redhat.com > wrote:
On 6/24/16 12:16 PM, Jan Lieskovsky wrote:
so there are these SSG "feature milestones" on GitHub:
* Infrastructure Enhancements and Fixes
* RHEL7 NIAP/USGCB Submission
* NIST 800-53 identifiers assignment
* Unimplemented OVAL checks
* RHEL-6 USGCB Profile Review
* Draft RHEL 7 STIG
There are two issues with the current approach:
* they are updated very seldom -- basically only in moment new release is
* they don't allow to reference all issues fixed in one particular release --
change is made (let's suppose it's related with RHEL 7 STIG effort), the
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
This way it will be possible to have just numeric milestones (0.1.31, 0.1.32,
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
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
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
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
> SCAP Security Guide mailing list