On Fri, Jun 24, 2016 at 10:19 AM, Shawn Wells <[email protected]> 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%20Enhancements%20and%20Fixes >> ) >> >> * RHEL7 NIAP/USGCB Submission >> ( >> https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USGCB%20Submission >> ) >> >> * NIST 800-53 identifiers assignment >> ( >> https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20identifiers%20assignment >> ) >> >> * Unimplemented OVAL checks >> ( >> https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20OVAL%20checks >> ) >> * RHEL-6 USGCB Profile Review >> ( >> https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%20Profile%20Review >> ) >> >> * Draft RHEL 7 STIG >> ( >> https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207%20STIG%20 >> ) >> >> 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
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
