Re: [VOTE] CHANGELOG.md file (second try)

+1 On Tue, Feb 27, 2018 at 2:50 PM, Jeremy Mitchell wrote: > I like that format. Bullets seems nice and simple with external links where > more info is required. > > I would be in favor of a PR to add these sections so it's easy for the next > person to add a bullet to

Re: [VOTE] CHANGELOG.md file (second try)

The keepachangelog folks seem to have done a great job describing a way that works. I'm +1 on re-using their work. :) On Tue, Feb 27, 2018 at 8:27 PM, Dave Neuman wrote: > +1 > > On Tue, Feb 27, 2018 at 14:50 Jeremy Mitchell wrote: > >> I like that

Re: Github PR/Issues Format Templates

If there's a relevant GitHub issue, that should be noted in the check-in comment, I think. Same for "what does it do?" I don't usually want to spell out steps for someone to verify my stuff because those are the steps that I took to verify it. The PR is so you can see the things I didn't see. And

Re: [VOTE] CHANGELOG.md file (second try)

+1 On Tue, Feb 27, 2018 at 14:50 Jeremy Mitchell wrote: > I like that format. Bullets seems nice and simple with external links where > more info is required. > > I would be in favor of a PR to add these sections so it's easy for the next > person to add a bullet to the

Re: Steering Target Geo-Ordering

Hey Eric, In this example I'd think that all the target DSes would need to be assigned to all 3 Cache Groups. That way the client could possibly use any of the target DSes from the cachegroup they're routed to. But I suppose that could change on a case-by-case basis where maybe the target DSes

Re: Github PR/Issues Format Templates

How about something like this for a PR template? What does this PR do? Is there a relevant Github issue? What is the best way to verify this PR? Does your PR include any of the following? - [ ] Tests - [ ] Documentation - [ ] CHANGELOG.md entry On Tue, Feb 27, 2018 at 10:46

Re: Steering Target Geo-Ordering

Makes perfect sense. thanks for the clarification. On Tue, Feb 27, 2018 at 11:32 AM, Rawlin Peters wrote: > Hey Jeremy, > > With a redundant origin in each location, there would be a total of 6 > HTTP_LIVE DSes. Then you'd create a steering DS with each of those 6 >

Re: Steering Target Geo-Ordering

Hey Jeremy, With a redundant origin in each location, there would be a total of 6 HTTP_LIVE DSes. Then you'd create a steering DS with each of those 6 HTTP_LIVE DSes as targets. The type of each target would either be GEO_ORDER or GEO_WEIGHT, depending on if we want a forced ordering or something

Re: Github PR/Issues Format Templates

With an issue and/or pr template, we will have 6/6 items checked: https://github.com/apache/incubator-trafficcontrol/community I actually think PR templates would be quite helpful. As a committer/merger, it would be nice to know what problem the PR is solving and how to verify the functionality.

Re: Steering Target Geo-Ordering

In this example, what would be the assignments of delivery services to edge Cache Groups? Are all 3DS’ assigned to all 3 Cache Groups? I’ll also assume that the content on the origins, while interchangeable from a clients perspective, is not identical? (i.e. might contain regionalized

Re: Google Summer of Code 2018 Mentor Registration

+1 on the API migration suggestion. On Mon, Feb 26, 2018 at 10:50 AM, Dave Neuman wrote: > I think any of the perl -> go API stuff would be great. > > On Mon, Feb 26, 2018 at 10:19 AM, Eric Friedrich (efriedri) < > efrie...@cisco.com> wrote: > > > I agree, this would be a