+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 great way to grow the c
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
content?)
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.
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
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
> HTTP_LIVE DSes as targets. Th
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 AM
Hey folks,
So I used the influxdb changelog as an example format, but @dew has
shown me this popular project for changelog convention:
http://keepachangelog.com/en/1.0.0/. For example see the project
changelog:
https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md.
Since we n
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 are
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 relevant section.
On Tue, Feb 27, 2018 at 2:15 PM, Rawlin Peters
wrote:
> Hey folks,
>
> S
+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 relevant section.
>
> On
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 t
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 format. Bullets seems nice and simple with exte
+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 the relevant section.
>
>
13 matches
Mail list logo