----- Original Message ----- > From: "Shawn Wells" <sh...@redhat.com> > To: scap-security-guide@lists.fedorahosted.org > Sent: Wednesday, September 3, 2014 3:43:59 AM > Subject: Re: Implementing GitHub Milestones > > On 9/2/14, 2:28 PM, Gabe Alford wrote: > > Hello list, > > > > I was thinking/pondering about this today, and was wondering if our > > project should implement milestones on GitHub. This way we can see the > > pull requests by milestone (historical) and set loose expectations > > about future milestones. (I say loose because priorities change, no > > one may be currently working on an issue, etc.) > > > > Milestones could match the existing versioning with > > scap-security-guide releases. (0.19, 0.20, etc.) > > Any pull request that is merged without an existing issue would be > > added to the existing milestone. Any issue that is not fixed in time > > for the monthly release will be moved to the next milestone. > > > > An example would be here: https://github.com/Netflix/Hystrix/milestones > > > > It may be beneficial, or might just be added process/work without a > > lot of beneficial use. Thoughts? > > > A thousand yes'!
+1 on this. Looks like very reasonable concept & something we / our users would definitely only profit from in the future once having the capability available. > > Seems very beneficial for major initiatives (e.g. RHEL6 USGCB, RHEL 7 > STIG), and would force a bit more planning than occurs now. Would also > allow us to setup 'blockers' for any issue that MUST be fixed before the > next release (e.g. OVAL errors). Speaking about blockers (issues that definitely need to go into next release) would it be possible to set up an agreement that such fixes would receive the [BLOCKER] prefix together with the [PATCH] prefix? To clarify the motivation a bit more - there's period in RHEL update cycle where we can include a rebase directly (just take the most recent upstream version with all patches & upgrade to it). But then there are also periods when the "rules for inclusion" are more strict (to ensure just stabilization fixes) during which only selected patches can be incorporated. It would be definitely helpful if such changes in each milestone would be marked as such (so we keep the list of them in mind & don't miss something during "patch inclusion window being opened"). Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team > > Having pull requests merged against the existing baseline would be huge > as well, especially for release note documentation. Any idea how to set > that up? > -- > 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/
