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?
Thanks,
Gabe
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?
----- Original Message -----
From: "Shawn Wells" shawn@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/
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?
Are you talking about adding a "Blocker" label to the pull request? Or when you `git commit` adding "[Blocker]" to your commit msg before you initiate a pull request?
Went ahead and added some milestones. Check them out here: https://github.com/OpenSCAP/scap-security-guide/milestones Also added a "BLOCKER" and "bugfix" label to the github labels.
On Wed, Sep 3, 2014 at 8:02 AM, Gabe Alford redhatrises@gmail.com wrote:
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?
Are you talking about adding a "Blocker" label to the pull request? Or when you `git commit` adding "[Blocker]" to your commit msg before you initiate a pull request?
On 9/3/14, 10:04 AM, Gabe Alford wrote:
Went ahead and added some milestones. Check them out here: https://github.com/OpenSCAP/scap-security-guide/milestones Also added a "BLOCKER" and "bugfix" label to the github labels.
Thank you so much for doing this! Also saw you went and tagged prior pull requests -- incredibly useful. There's.... room for improvement... in the release notes, and this will really enable getting better changelogs out
----- Original Message -----
From: "Gabe Alford" redhatrises@gmail.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, September 3, 2014 4:04:33 PM Subject: Re: Implementing GitHub Milestones
Went ahead and added some milestones. Check them out here: https://github.com/OpenSCAP/scap-security-guide/milestones Also added a "BLOCKER" and "bugfix" label to the github labels.
Wonderful, thanks for that.
Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Wed, Sep 3, 2014 at 8:02 AM, Gabe Alford < redhatrises@gmail.com > wrote:
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?
Are you talking about adding a "Blocker" label to the pull request? Or when you `git commit` adding "[Blocker]" to your commit msg before you initiate a pull request?
-- 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/
On 9/3/14, 10:02 AM, Gabe Alford wrote:
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?Are you talking about adding a "Blocker" label to the pull request? Or when you `git commit` adding "[Blocker]" to your commit msg before you initiate a pull request?
Label in the repo that we could query against, ideally.
On Wed, Sep 3, 2014 at 10:03 PM, Shawn Wells shawn@redhat.com wrote:
On 9/3/14, 10:02 AM, Gabe Alford wrote:
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?
Are you talking about adding a "Blocker" label to the pull request? Or when you `git commit` adding "[Blocker]" to your commit msg before you initiate a pull request?
Label in the repo that we could query against, ideally.
Would `git log` or `git shortlog` work for this? It could easily be scripted with either of those.
----- Original Message -----
From: "Gabe Alford" redhatrises@gmail.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, September 3, 2014 4:02:04 PM Subject: Re: Implementing GitHub Milestones
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?
Are you talking about adding a "Blocker" label to the pull request? Or when you `git commit` adding "[Blocker]" to your commit msg before you initiate a pull request?
Basically both of them might be handy. "Blocker" label in the pull request due to the fact, often the pull request contains more than just one patch (not to need repeatedly insert them for bigger patchset).
For case of committing - corresponding git hook (checking if the git log message contains at least one of [blocker], [bugfix], [enhancement], .. any others?) would be handy to prevent log messages not specifying type of change.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-- 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/
For case of committing - corresponding git hook (checking if the git log message contains at least one of [blocker], [bugfix], [enhancement], .. any others?) would be handy to prevent log messages not specifying type of change.
Correct me if I am wrong, but this would most likely need to be implemented through GitHub Webhook API https://developer.github.com/v3/repos/hooks/ which looks like a pain?
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?
Do you mean that all pull requests from the time github use started to today be added to the 0.1.19 milestone? Or.....?
On 9/3/14, 9:59 AM, Gabe Alford wrote:
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?Do you mean that all pull requests from the time github use started to today be added to the 0.1.19 milestone? Or.....?
I may have misread your note.
What I *though* I read was there was a magical way to automatically associate new pull requests with a specific milestone label. This would be very, very cool, but can't find any docs on if that's possible (e.g. marking the patch in some special way, giving it some special commit tag, etc). If possible, awesome! If not, oh well.
On Wed, Sep 3, 2014 at 10:03 PM, Shawn Wells shawn@redhat.com wrote:
On 9/3/14, 9:59 AM, Gabe Alford wrote:
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?
Do you mean that all pull requests from the time github use started to today be added to the 0.1.19 milestone? Or.....?
I may have misread your note.
What I *though* I read was there was a magical way to automatically associate new pull requests with a specific milestone label. This would be very, very cool, but can't find any docs on if that's possible (e.g. marking the patch in some special way, giving it some special commit tag, etc). If possible, awesome! If not, oh well.
It looks like at this point a lot of it is a manual process which the pull requestor or the merger could just make sure it is associated with the correct milestone. Someone would need to open/close milestones as once a milestone is needed/completed. There might be a way to do this through github webhooks https://developer.github.com/webhooks/. Not sure if any of these software products would work: https://github.com/stephencelis/ghi or https://github.com/node-gh/gh
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Jan Lieskovsky -
Shawn Wells