Jeremy,
I am +1 on everything you mentioned. I am also willing to volunteer time from
myself and Ashish to review and update all open requests for project, label,
etc…
Ryan DurfeyM | 303-524-5099
CDN Support (24x7): 866-405-2993 or
cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>
From: Jeremy Mitchell <mitchell...@apache.org>
Reply-To: "dev@trafficcontrol.incubator.apache.org"
<dev@trafficcontrol.incubator.apache.org>
Date: Thursday, November 16, 2017 at 8:07 AM
To: "dev@trafficcontrol.incubator.apache.org"
<dev@trafficcontrol.incubator.apache.org>
Subject: Scoping a release
At the Traffic Control summit, we discussed the need to do a better job
scoping releases. What changes can I expect in an upcoming release? What
changes went in to a completed release?
The only way I can think to do this (without having a release manager that
actively manages the scope of a release) is to leverage Github labels and
milestones on issues and PRs.
For example, when creating an issue or a PR, make sure it has one or more
component labels (Traffic Ops, Traffic Monitor, etc) on it at a minimum. If
you are unable to attach labels, reach out to a "committer". They can add
labels for you.
Also, if you plan to work on an issue, make sure you assign it to yourself
(or put a comment that you are working on it) and select the appropriate
milestone. (again, ask a "committer" if you can't assign the milestone)
By using labels and milestones, I think it should be pretty easy to see
what is going in / went in to a particular release.
thoughts?
jeremy
