On 9/2/14, 2:28 PM, Gabe Alford wrote:
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