Implementing GitHub Milestones

Jan Lieskovsky jlieskov at redhat.com
Wed Sep 3 08:18:08 UTC 2014


----- Original Message -----
> From: "Shawn Wells" <shawn at redhat.com>
> To: scap-security-guide at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/


More information about the scap-security-guide mailing list