Implementing GitHub Milestones

Shawn Wells shawn at redhat.com
Wed Sep 3 01:43:59 UTC 2014


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'!

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).

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?


More information about the scap-security-guide mailing list