Hey all, So it appears this vote passed in favor of adding a CHANGELOG.md file without having a changelog label in GitHub. Is anyone currently working on one?
With the 2.2 release planned for 2/12/18, I'd like to at least put in some upgrade release notes about Per-Delivery-Service Routing Names. If no one has a CHANGELOG.md in progress, I'll take the liberty to start one and add those release notes in there (using https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md as an example template). -Rawlin On Wed, Jan 10, 2018 at 10:35 AM, Chris Lemmons <[email protected]> wrote: > [X] +1 to adding a changelog.MD file > [] -1 to adding a changelog.MD file > > That said, I'm only in favour of it if we're fastidious about > requiring changelog updates on every single PR. A PR should either > provide a reasonable changelog entry, or, in the body of the PR, > justify it's absence. A simple "This bugfix does not require a > changelog entry." is sufficient for trivial bugfixes. That's plenty > for a reviewer to quickly either agree or decide to request (or > provide) an entry. > > If we add the changelog file, we need to update the contributing file > to include the new guidelines. > > On Wed, Jan 10, 2018 at 9:14 AM, Jeremy Mitchell <[email protected]> > wrote: >> Yes, I was about to mention milestones. Why not leverage Github milestones >> on issues/PRs? We talked about using milestones at the last TC summit to >> determine the scope of a release. Now is our chance to do that. >> >> Milestones can be applied to issues or PRs. I tend to create issues for >> everything I do, so I would put the milestone on the issue but others can >> simply put a milestone on their PR (if there is no related issue). Either >> way, it tags the items we want included in the changelog. And then the RM >> can build the changelog from the milestones. Easy peasy. >> >> Jeremy >> >> >> >> >> >> >> On Tue, Jan 9, 2018 at 4:56 PM, Leif Hedstrom <[email protected]> wrote: >> >>> >>> >>> > On Jan 9, 2018, at 10:22 AM, Dave Neuman <[email protected]> wrote: >>> > >>> > Looks like this thread died over the holidays. Let me try to bring it >>> back >>> > up before we cut a 2.2 branch. >>> > Can you please respond with *just* the following: >>> > >>> > [X] +1 to adding a changelog.MD file >>> > [] -1 to adding a changelog.MD file >>> > >>> > [] +1 to adding a changelog label in github >>> > [X] -1 to adding a changelog label in github >>> > >>> >>> >>> To add to the previous thread / thoughts. I feel reasonably strongly that >>> having a changelog label in Github is not useful. In the ATS community, we >>> can *barely* get people to set the Milestone properly, and I feel that the >>> Milestone is a much more important thing to keep accurate than anything >>> else. And, to be normalized, you don’t want to duplicate this info :-). >>> >>> So, what we do is have the RM be like a hawk over the Milestones, and then >>> run Phil’s fancy pants script to generate the ChangeLog from the Milestones >>> on all PRs closed. >>> >>> Cheers, >>> >>> — leif >>> >>> > Thanks, >>> > Dave >>> > >>> > On Fri, Dec 15, 2017 at 9:14 AM, Dewayne Richardson <[email protected]> >>> > wrote: >>> > >>> >> +1 on the CHANGELOG.md as well, but I like having the changelog label >>> >> because it helps streamline it's creation. I also think the labels are >>> >> valuable because they help summarize the parts of the repo that changed >>> and >>> >> keeps the concept closer to the repository (where the real change is). >>> >> >>> >> -Dew >>> >> >>> >> On Thu, Dec 14, 2017 at 3:01 PM, Robert Butts <[email protected] >>> > >>> >> wrote: >>> >> >>> >>> +1. To clarify, I'm +1 on having the "changelog" label, to help whoever >>> >>> manually goes thru and builds the CHANGELOG.md. >>> >>> >>> >>> But I agree with @neuman I don't think we can automate this. Titles are >>> >> too >>> >>> short, some changes need longer explanations and some don't, only a >>> human >>> >>> can figure out how important something is to users; a high priority bug >>> >> fix >>> >>> could still be low-impact, or vica-versa. Much as I dislike manual >>> >> things, >>> >>> this really needs human judgement. And we absolutely need a good >>> >> Changelog >>> >>> with each Release. >>> >>> >>> >>> On Thu, Dec 14, 2017 at 2:36 PM, Dave Neuman <[email protected]> >>> wrote: >>> >>> >>> >>>> Thanks for putting that together Dewayne. I was just starting to do >>> >> that >>> >>>> myself when I saw it was already done. >>> >>>> As a developer this is fine, I can see a list of PRs and click on each >>> >>> one >>> >>>> to see the whole conversation. I can comb through them and get a >>> >> general >>> >>>> sense for what changed. >>> >>>> >>> >>>> However, as an operator and user of Traffic Control (which I mostly am >>> >>>> these days) I am -1 for the following reasons: >>> >>>> 1) only committers can assign labels to issues and pull requests. >>> This >>> >>>> means that the committers need to be cognizant of the issues/PRs they >>> >> are >>> >>>> reviewing and apply the change log label; >>> >>>> 2) the title of a PR only gives so much information about a change, if >>> >> I >>> >>>> want more information I have to click on each individual one >>> >>>> 3) If I am not a developer, or someone who is very familiar with our >>> >>>> project, it is hard for me to ascertain from this list which changes >>> >> are >>> >>>> super-important or have some operational considerations attached to >>> >> them. >>> >>>> These are the issues I really care about. >>> >>>> 4) When I go to do an upgrade, it's a lot easier to copy/paste a nice >>> >>>> bulleted list of what changed then it is to try to take a list of PRs >>> >> and >>> >>>> turn it into a high level list of what's important. >>> >>>> >>> >>>> We need a solution that gives someone what they need at a glance. >>> >>> Something >>> >>>> that can be copy/pasted out or easily linked to. IMO not all of our >>> >>> users >>> >>>> are super technical or involved in the day to day so we shouldn't just >>> >>>> point them at a list of PRs and say "figure it out"; we should make it >>> >>> easy >>> >>>> for them to figure out. >>> >>>> >>> >>>> I have seen lots of alternatives suggested to what Steve has proposed, >>> >>> but >>> >>>> I haven't seen anyone state why they don't like what Steve has >>> >>> proposed? I >>> >>>> think what he is proposing is pretty standard across major Github >>> >>> projects >>> >>>> that I have seen. I understand that we can introduce some additional >>> >>>> inconvenience with having to manually write what your feature or bug >>> >> fix >>> >>>> does, and there could be some conflicts, but isn't it important to >>> >>> clearly >>> >>>> portray what has changed? I don't think we need a changelog.md entry >>> >> to >>> >>>> every PR, in fact I hope we don't...we need a changelog.md entry any >>> >>> time >>> >>>> we add a new feature, any time we have some operational considerations >>> >>> that >>> >>>> need to be communicated, or any time that we fix a bug from a previous >>> >>>> release. >>> >>>> >>> >>>> >>> >>>> On Thu, Dec 14, 2017 at 2:02 PM, Jeremy Mitchell < >>> >> [email protected]> >>> >>>> wrote: >>> >>>> >>> >>>>> This label idea would require everyone to go back and find their PRs >>> >>> that >>> >>>>> were closed after Aug 4th (the date 2.1 branch was created) and >>> >> attach >>> >>>> the >>> >>>>> 'change log' label and the 2.2 milestone to the appropriate ones, >>> >>> right? >>> >>>>> And then that link dew provide would be an accurate picture of what >>> >> has >>> >>>>> changed between 21. and 2.2... >>> >>>>> >>> >>>>> of course, ignore PRs that don't affect the "interface" like "license >>> >>>>> changes", right? >>> >>>>> >>> >>>>> i like the idea... >>> >>>>> >>> >>>>> On Thu, Dec 14, 2017 at 1:59 PM, Dewayne Richardson < >>> >> [email protected] >>> >>>> >>> >>>>> wrote: >>> >>>>> >>> >>>>>> As a POC for the Change Log label follow this link: >>> >>>>>> >>> >>>>>> https://github.com/apache/incubator-trafficcontrol/ >>> >>>>>> pulls?q=is%3Apr+is%3Aclosed+label%3A%22change+log%22+ >>> >>> milestone%3A2.2.0 >>> >>>>>> >>> >>>>>> -Dew >>> >>>>>> >>> >>>>>> On Thu, Dec 14, 2017 at 10:48 AM, Gelinas, Derek < >>> >>>>>> [email protected]> >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>>> I'm +1 for the label as well. >>> >>>>>>> >>> >>>>>>>> On Dec 14, 2017, at 12:29 PM, Robert Butts < >>> >>>> [email protected] >>> >>>>>> >>> >>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>> +1 on a "changelog" label. Seems like that would make it a lot >>> >>>> easier >>> >>>>>> for >>> >>>>>>>> the person writing it up. Easier to skip things like code >>> >>>> maintenance >>> >>>>>>> that >>> >>>>>>>> have no interface effect. >>> >>>>>>>> >>> >>>>>>>> On Thu, Dec 14, 2017 at 10:14 AM, Dewayne Richardson < >>> >>>>>> [email protected]> >>> >>>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>>> Another idea would be to include a new CHANGELOG label that >>> >> you >>> >>>>> could >>> >>>>>>> tack >>> >>>>>>>>> onto specific PR's that you wanted to be included (as well as >>> >>>>> grouped >>> >>>>>>>>> within Milestones) as the high level features that went into >>> >> the >>> >>>>>>> release. >>> >>>>>>>>> As for the gotchas, I think those should be Github issues >>> >>> because >>> >>>> to >>> >>>>>> me >>> >>>>>>>>> those were bugs. >>> >>>>>>>>> >>> >>>>>>>>> -Dew >>> >>>>>>>>> >>> >>>>>>>>> On Thu, Dec 14, 2017 at 10:01 AM, Jeremy Mitchell < >>> >>>>>>> [email protected]> >>> >>>>>>>>> wrote: >>> >>>>>>>>> >>> >>>>>>>>>> I agree. Very readable. I also like the idea of a either >>> >>>> creating a >>> >>>>>>>>>> CHANGELOG.md for each component...or one CHANGELOG.md with >>> >>>> sections >>> >>>>>> for >>> >>>>>>>>>> each component. >>> >>>>>>>>>> >>> >>>>>>>>>> I still do like the idea of creating issues with milestones >>> >> but >>> >>>>> I'll >>> >>>>>>> let >>> >>>>>>>>>> that go. That seems to be a personal preference of mine. >>> >>>>>>>>>> >>> >>>>>>>>>> Jeremy >>> >>>>>>>>>> >>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 9:45 AM, Dave Neuman < >>> >>> [email protected] >>> >>>>> >>> >>>>>>> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> Have you taken a look at some Changelogs of other github >>> >>>> projects? >>> >>>>>>>>> Here >>> >>>>>>>>>>> are a few from other projects we use in Traffic Control: >>> >>>>>>>>>>> - Docker Compose: https://github.com/docker/ >>> >>>>>>>>>> compose/blob/master/CHANGELOG. >>> >>>>>>>>>>> md >>> >>>>>>>>>>> - InfluxDB: https://github.com/influxdata/ >>> >>> influxdb/blob/master/ >>> >>>>>>>>>>> CHANGELOG.md >>> >>>>>>>>>>> - Grafana: https://github.com/grafana/ >>> >>>>> grafana/blob/master/CHANGELOG >>> >>>>>> . >>> >>>>>>> md >>> >>>>>>>>>>> - Ansible: https://github.com/ansible/ >>> >>>>> ansible/blob/devel/CHANGELOG. >>> >>>>>> md >>> >>>>>>>>>>> >>> >>>>>>>>>>> See how easy to read those are and how they provide a lot of >>> >>>>>>>>> information >>> >>>>>>>>>>> without having to wade through hundreds of issues and pull >>> >>>>> requests? >>> >>>>>>>>>> Some >>> >>>>>>>>>>> of them also have links to issues for new features, as well >>> >> as >>> >>>> bug >>> >>>>>>>>> fixes >>> >>>>>>>>>>> that are in the current release. I think all of them are >>> >> easy >>> >>>> to >>> >>>>>> read >>> >>>>>>>>>> and >>> >>>>>>>>>>> can give a user a quick overview of what is in the new >>> >>> release. >>> >>>> I >>> >>>>>>> think >>> >>>>>>>>>>> it's fine to add a link to all the issues if we want, but I >>> >>>> think >>> >>>>>>>>>>> ultimately we want to create something like what I have >>> >> linked >>> >>>> to >>> >>>>>>>>> above. >>> >>>>>>>>>>> We might also want to break out our CHANGELOG.md by >>> >> component >>> >>> to >>> >>>>>>>>> provide >>> >>>>>>>>>>> even more readability. >>> >>>>>>>>>>> >>> >>>>>>>>>>> I know our first inclination is to try to automate >>> >> everything, >>> >>>> but >>> >>>>>>>>>>> sometimes it makes sense to do things manually so that you >>> >> can >>> >>>>>> create >>> >>>>>>> a >>> >>>>>>>>>>> better output. >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 8:55 AM, Jeremy Mitchell < >>> >>>>>>>>> [email protected]> >>> >>>>>>>>>>> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>>> What if CHANGLOG.md includes 2 things: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> 1. a link to 2.2 issues (i.e. >>> >>>>>>>>>>>> https://github.com/apache/incubator-trafficcontrol/ >>> >>>>>>>>>>>> issues?q=is%3Aopen+is%3Aissue+milestone%3A2.2.0 >>> >>>>>>>>>>>> 2. a bulleted list of 2.2 gotchas (i.e. Traffic Ops Golang >>> >>>>> doesn't >>> >>>>>>>>>>> connect >>> >>>>>>>>>>>> to a Riak with self-signed certificates; Riak security >>> >> grant >>> >>>>> needs >>> >>>>>>>>>>> updated; >>> >>>>>>>>>>>> upgrade param needed for ds routing names, etc, etc...) >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> But again this requires everyone to create issues (with a >>> >>>>>> milestone) >>> >>>>>>>>> in >>> >>>>>>>>>>>> which one or more PR's can be attached to. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Dave, you said "If you are developing a new feature you >>> >> could >>> >>>>>> easily >>> >>>>>>>>>> end >>> >>>>>>>>>>> up >>> >>>>>>>>>>>> with 5 or more PRs" >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> So in this case, I'd expect 1 issue and 5 PR's linked to >>> >>> that 1 >>> >>>>>>>>>> issue... >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Jeremy >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 8:40 AM, Dave Neuman < >>> >>>> [email protected]> >>> >>>>>>>>>> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> I think it's fine to include all of our PRs and issues in >>> >> a >>> >>>>> github >>> >>>>>>>>>>>>> milestone, and we should do that, but I don't think that >>> >> we >>> >>>> want >>> >>>>>> to >>> >>>>>>>>>>>> include >>> >>>>>>>>>>>>> every single PR in our changelog. When we have tried that >>> >>> in >>> >>>>> the >>> >>>>>>>>>> past >>> >>>>>>>>>>> we >>> >>>>>>>>>>>>> have realized that it gets to be so much information that >>> >>> it's >>> >>>>> not >>> >>>>>>>>>>>> useful. >>> >>>>>>>>>>>>> A good example of why is a new feature. If you are >>> >>> developing >>> >>>> a >>> >>>>>> new >>> >>>>>>>>>>>> feature >>> >>>>>>>>>>>>> you could easily end up with 5 or more PRs: one to >>> >> introduce >>> >>>> the >>> >>>>>>>>>>> feature, >>> >>>>>>>>>>>>> one to add some more functionality, several to fix bugs >>> >> with >>> >>>> it, >>> >>>>>>>>> etc. >>> >>>>>>>>>>>>> Instead of having a line in the changelog for each one of >>> >>>> those >>> >>>>>>>>> PRs, >>> >>>>>>>>>> we >>> >>>>>>>>>>>>> should just have one line that says "introduced feature X" >>> >>>> with >>> >>>>>>>>>> maybe a >>> >>>>>>>>>>>>> blurb about what it is and any release notes that an >>> >>> operator >>> >>>>>> would >>> >>>>>>>>>>> need >>> >>>>>>>>>>>> to >>> >>>>>>>>>>>>> know. This way the file in concise and easy to understand >>> >>> by >>> >>>>>>>>> anyone >>> >>>>>>>>>>>>> wanting to use a new version of our product. I think it's >>> >>>> also >>> >>>>>>>>>>> important >>> >>>>>>>>>>>>> to include what bug fixes (since the previous release) >>> >> that >>> >>> we >>> >>>>>> have >>> >>>>>>>>>>>> fixed. >>> >>>>>>>>>>>>> Those are the reasons why I tend to lean towards a manual >>> >>>>>>>>> changelog. >>> >>>>>>>>>>> It >>> >>>>>>>>>>>>> gives us the ability to control how much information goes >>> >>> into >>> >>>>> the >>> >>>>>>>>>>>>> changelog and the flexibility to make sure it is useful. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 8:13 AM, Jeremy Mitchell < >>> >>>>>>>>>>> [email protected]> >>> >>>>>>>>>>>>> wrote: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Why not leverage Github issues/milestones to determine >>> >> the >>> >>>>> scope >>> >>>>>>>>> of >>> >>>>>>>>>>>> each >>> >>>>>>>>>>>>>> release? Per our CONTRIBUTING.md >>> >>>>>>>>>>>>>> <https://github.com/apache/ >>> >> incubator-trafficcontrol/blob/ >>> >>>>>>>>>>>>>> master/CONTRIBUTING.md> >>> >>>>>>>>>>>>>> : >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> "If you have improvements (enhancements or bug fixes) for >>> >>>>> Traffic >>> >>>>>>>>>>>>> Control, >>> >>>>>>>>>>>>>> start by creating an issue >>> >>>>>>>>>>>>>> <https://github.com/apache/incubator-trafficcontrol/ >>> >> issues >>> >>>>>> ..." >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> That implies that all PR's should be mapped to an issue >>> >>>>> although >>> >>>>>>>>> we >>> >>>>>>>>>>> do >>> >>>>>>>>>>>>> not >>> >>>>>>>>>>>>>> enforce this but if we did it would be easy to put each >>> >>> issue >>> >>>>>>>>> into >>> >>>>>>>>>> a >>> >>>>>>>>>>>>>> milestone (2.2 for example) and then pull a github report >>> >>> at >>> >>>>> any >>> >>>>>>>>>>> time. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Or....rather than creating an issue, put a good >>> >>>>> title/description >>> >>>>>>>>>> on >>> >>>>>>>>>>>> your >>> >>>>>>>>>>>>>> PR and then the PR can be assigned to the milestone >>> >>> instead. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> It just seems like that's what milestones are for so why >>> >>> not >>> >>>>> use >>> >>>>>>>>>>> them? >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Jeremy >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> On Wed, Dec 13, 2017 at 3:28 PM, Dave Neuman < >>> >>>>> [email protected]> >>> >>>>>>>>>>>> wrote: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> I am +1 on this approach, I know it's manual and there >>> >>> could >>> >>>>> be >>> >>>>>>>>>>>>> conflicts >>> >>>>>>>>>>>>>>> and it's a bit of a PITA, but I think it actually has >>> >> some >>> >>>>>>>>>> benefits >>> >>>>>>>>>>>> in >>> >>>>>>>>>>>>>> that >>> >>>>>>>>>>>>>>> a human can actually enter in important release notes >>> >> that >>> >>>> are >>> >>>>>>>>>>>> readable >>> >>>>>>>>>>>>>> and >>> >>>>>>>>>>>>>>> make sense. >>> >>>>>>>>>>>>>>> That being said if someone is willing to make an >>> >> automated >>> >>>>>>>>>> approach >>> >>>>>>>>>>>>> work, >>> >>>>>>>>>>>>>>> that allows us to keep track of changes at a reasonable >>> >>>> level >>> >>>>>>>>>> (not >>> >>>>>>>>>>>> per >>> >>>>>>>>>>>>>>> commit, not necessarily even per PR), then I could be +1 >>> >>> on >>> >>>>>>>>> that >>> >>>>>>>>>> as >>> >>>>>>>>>>>>> well. >>> >>>>>>>>>>>>>>> I would need to someone volunteer to make it work >>> >> before I >>> >>>>> give >>> >>>>>>>>>> my >>> >>>>>>>>>>> +1 >>> >>>>>>>>>>>>>>> though. >>> >>>>>>>>>>>>>>> Either way, we REALLY need a changelog that is updated >>> >>>>>>>>> regularly >>> >>>>>>>>>>> with >>> >>>>>>>>>>>>>>> important information. >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> --Dave >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> On Wed, Dec 13, 2017 at 3:00 PM, Steve Malenfant < >>> >>>>>>>>>>>> [email protected] >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> wrote: >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Hey All, >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> There has been a vote on not maintaining a CHANGELOG >>> >> file >>> >>>> in >>> >>>>>>>>>> the >>> >>>>>>>>>>>> past >>> >>>>>>>>>>>>>> and >>> >>>>>>>>>>>>>>>> seems like we leaned toward an automated process. I >>> >>> believe >>> >>>>>>>>>> none >>> >>>>>>>>>>> of >>> >>>>>>>>>>>>>> them >>> >>>>>>>>>>>>>>>> had happened (please correct me if not). >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> I have been upgrading Traffic Control from 2.1 to 2.2 >>> >>> this >>> >>>>>>>>> week >>> >>>>>>>>>>> and >>> >>>>>>>>>>>>>> found >>> >>>>>>>>>>>>>>>> numerous gotchas. >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Some examples of things I ran into and luckily I was >>> >> able >>> >>>> to >>> >>>>>>>>>> get >>> >>>>>>>>>>>> good >>> >>>>>>>>>>>>>>>> support from the Slack channels. Here is a few example >>> >> of >>> >>>>>>>>>>> possible >>> >>>>>>>>>>>>>>> breaking >>> >>>>>>>>>>>>>>>> changes : >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> - Delivery Service prefixes disappeared after upgrade, >>> >>> was >>> >>>>>>>>> not >>> >>>>>>>>>>>>> handled >>> >>>>>>>>>>>>>> in >>> >>>>>>>>>>>>>>>> postinstall (requires special attention, this was on >>> >> this >>> >>>>>>>>> forum >>> >>>>>>>>>>> and >>> >>>>>>>>>>>>>> well >>> >>>>>>>>>>>>>>>> documented on the mailing list) >>> >>>>>>>>>>>>>>>> - Traffic Ops Golang doesn't connect to a Riak with >>> >>>>>>>>> self-signed >>> >>>>>>>>>>>>>>>> certificates >>> >>>>>>>>>>>>>>>> - Riak security grant needs updated >>> >>>>>>>>>>>>>>>> - cdn.conf configuration change >>> >>>>>>>>>>>>>>>> - Traffic Portal required for new features (URI >>> >> Signing) >>> >>>>>>>>>>>>>>>> - cachekey plugin instead of cacheurl >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> There was great enhancements made in 2.2 needs to be >>> >>>> noticed >>> >>>>>>>>> by >>> >>>>>>>>>>>>> current >>> >>>>>>>>>>>>>>> and >>> >>>>>>>>>>>>>>>> new users. If we are looking to get more engagement, >>> >>>> that's >>> >>>>>>>>>>>> probably >>> >>>>>>>>>>>>>> the >>> >>>>>>>>>>>>>>>> #1 thing to do. I usually go and read about all the >>> >> other >>> >>>>>>>>>>>> components >>> >>>>>>>>>>>>>>> which >>> >>>>>>>>>>>>>>>> we use around the Traffic Control CDN (Influx, Elastic, >>> >>>>>>>>>> Grafana, >>> >>>>>>>>>>>>>> etc...) >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> So let me re-quote what Dave has sent and ask the same >>> >>>>>>>>> question >>> >>>>>>>>>>>>> again. >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> ====== >>> >>>>>>>>>>>>>>>> Hey All, >>> >>>>>>>>>>>>>>>> One thing we discussed at the meetup was the addition >>> >> of >>> >>> a >>> >>>>>>>>>>>>> CHANGELOG.md >>> >>>>>>>>>>>>>>>> file to the project. This file will contain changes >>> >>> that >>> >>>>>>>>> are >>> >>>>>>>>>>> made >>> >>>>>>>>>>>>> to >>> >>>>>>>>>>>>>>> the >>> >>>>>>>>>>>>>>>> project including bug fixes and new features. (e.g. >>> >>>>>>>>>>>>>>>> https://github.com/influxdata/influxdb/blob/master/ >>> >>>>>>>>>> CHANGELOG.md >>> >>>>>>>>>>> ). >>> >>>>>>>>>>>>>>> Adding >>> >>>>>>>>>>>>>>>> this file means that we will now require each PR to >>> >>> contain >>> >>>>>>>>> an >>> >>>>>>>>>>>> update >>> >>>>>>>>>>>>>> to >>> >>>>>>>>>>>>>>>> the CHANGELOG.md file, and our documentation will need >>> >> to >>> >>>> be >>> >>>>>>>>>>>> updated >>> >>>>>>>>>>>>>>>> accordingly. >>> >>>>>>>>>>>>>>>> I thought it would be good to open a vote for adding >>> >> this >>> >>>>>>>>> file, >>> >>>>>>>>>>> and >>> >>>>>>>>>>>>> if >>> >>>>>>>>>>>>>> it >>> >>>>>>>>>>>>>>>> passes, I will update the documentation and add a >>> >>>>>>>>> CHANGELOG.md >>> >>>>>>>>>>>> file. >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Thanks, >>> >>>>>>>>>>>>>>>> Dave >>> >>>>>>>>>>>>>>>> ====== >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> I'm a +1 on CHANGELOG, but I'm not heavy creating PRs >>> >>> which >>> >>>>>>>>>> kind >>> >>>>>>>>>>>>>>> influence >>> >>>>>>>>>>>>>>>> my vote. >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Steve >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>> >>> >>> >>> >> >>> >>>
