Dear podling,
This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.
The board meeting is scheduled for Wed, 18 July 2018, 10:30 am PDT.
The report for your podling will form a
replies inline
On Wed, Jun 27, 2018 at 2:17 PM Robert Butts wrote:
>
> I'm inclined to agree with not adding new DS types.
>
> Yeah, we'll need code for `if go_direct is undefined...`, but I'm pretty
> sure we'd need equal or more code, across all our apps, to handle the new
> types. We have a to
replies inline
On Wed, Jun 27, 2018 at 10:59 AM Eric Friedrich (efriedri)
wrote:
>
> Regardless of adding a new DS type, we’ll always have incompatibility between
> features. In this case, we could create new DS types for the _BYPASS, but we
> would then still need to block enabling MSO on thos
I'm inclined to agree with not adding new DS types.
Yeah, we'll need code for `if go_direct is undefined...`, but I'm pretty
sure we'd need equal or more code, across all our apps, to handle the new
types. We have a ton of code that checks `if dstype == HTTP_LIVE { ... }
else if dstype == HTTP_LIV
Regardless of adding a new DS type, we’ll always have incompatibility between
features. In this case, we could create new DS types for the _BYPASS, but we
would then still need to block enabling MSO on those delivery services.
A few more comments inline
> On Jun 27, 2018, at 12:08 PM, Rawlin Pe
Alright, I'm going to try to walk through this from the dev
perspective a bit too. Say we add a go_direct column (non-null,
default false) to the deliveryservice table. We can't add a new
required field to the API without breaking it, so the API backend has
to do a check like this before inserting
