Date   

Re: [vpp-dev] Replacing master/slave nomenclature

Edward Warnicke
 

This is a pretty good summary of various suggestions for replacement terms:


Ed

On Tue, Jul 14, 2020 at 11:36 AM Jerome Tollet via lists.fd.io <jtollet=cisco.com@...> wrote:
Hi Steven,
Please note that per this proposition,  https://lkml.org/lkml/2020/7/4/229, slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@... au nom de steven luong via lists.fd.io » <vpp-dev@... au nom de sluong=cisco.com@...> a écrit :

    I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

    Steven

    On 7/13/20, 4:44 AM, "vpp-dev@... on behalf of Dave Barach via lists.fd.io" <vpp-dev@... on behalf of dbarach=cisco.com@...> wrote:

        +1, especially since our next release will be supported for a year, and API name changes are involved...

        -----Original Message-----
        From: Kinsella, Ray <mdr@...>
        Sent: Monday, July 13, 2020 6:01 AM
        To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
        Subject: Re: [vpp-dev] Replacing master/slave nomenclature

        Hi Stephen,

        I agree, I don't think we should ignore this.
        Ed - I suggest we table a discussion at the next FD.io TSC?

        Ray K

        On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
        > Looping in the technical steering committee...
        >
        > -----Original Message-----
        > From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
        > Sent: Thursday, July 2, 2020 7:02 PM
        > To: vpp-dev@...
        > Subject: [vpp-dev] Replacing master/slave nomenclature
        >
        > Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI?  We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
        >
        > Particularly problematic is the use of master/slave in bonding.
        > This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
        >
        > The IEEE and IETF are doing an across the board look at these terms in standards.
        >
        >
        >
        >




Re: [vpp-dev] Replacing master/slave nomenclature

Jerome Tollet
 

Hi Steven,
Please note that per this proposition, https://lkml.org/lkml/2020/7/4/229, slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@... au nom de steven luong via lists.fd.io » <vpp-dev@... au nom de sluong=cisco.com@...> a écrit :

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@... on behalf of Dave Barach via lists.fd.io" <vpp-dev@... on behalf of dbarach=cisco.com@...> wrote:

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@...>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering committee...
>
> -----Original Message-----
> From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
> Sent: Thursday, July 2, 2020 7:02 PM
> To: vpp-dev@...
> Subject: [vpp-dev] Replacing master/slave nomenclature
>
> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>
> Particularly problematic is the use of master/slave in bonding.
> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>
> The IEEE and IETF are doing an across the board look at these terms in standards.
>
>
>
>


Re: Published: FD.io CSIT-2005 Release Report

Dave Wallace
 

Congratulations to all!
-daw-

On 7/14/2020 9:33 AM, Maciek Konstantynowicz (mkonstan) via lists.fd.io wrote:
Hi All,

FD.io CSIT-2005 report has been published on FD.io docs site:

    https://docs.fd.io/csit/rls2005/report/

Many thanks to All in CSIT, VPP and wider FD.io community who
contributed and worked hard to make CSIT-2005 happen!

See below for pointers to specific sections in the report.

Welcome all comments, best by email to csit-dev@....

Cheers,
-Maciek

------------------------------------------------------------------------
Points of Note in the CSIT-2005 Report
------------------------------------------------------------------------
Indexed specific links listed at the bottom.

1. VPP release notes
   a. Changes in CSIT-2005:     [1]
   b. Known issues:             [2]

2. VPP performance - 64B/IMIX throughput graphs (selected NIC models):
   a. Graphs explained:         [3]
   b. L2 Ethernet Switching:    [4]
   c. IPv4 Routing:             [5]
   d. IPv6 Routing:             [6]
   e. SRv6 Routing:             [7]
   f. IPv4 Tunnels:             [8]
   g. KVM VMs vhost-user:       [9]
   h. LXC/DRC Container Memif: [10]
   e. IPsec IPv4 Routing:      [11]
   f. Virtual Topology System: [12]

3. VPP performance - multi-core and latency graphs:
   a. Speedup Multi-Core:      [13]
   b. Latency:                 [14]

4. VPP performance comparisons
   a. VPP-20.05 vs. VPP-20.01:              [15]

5. VPP performance test details - all NICs:
   a. Detailed results 64B IMIX 1518B 9kB:  [16]
   b. Configuration:                        [17]

DPDK Testpmd and L3fwd performance sections follow similar structure.

6. DPDK applications:
  a. Release notes:                               [18]
  b. DPDK performance - 64B throughput graphs:    [19]
  c. DPDK performance - latency graphs:           [20]
  d. DPDK performance - DPDK-20.02 vs. DPDK-19.08: [21]

Functional device tests (VPP_Device) are also included in the report.

Specific links within the report:

 [1] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#changes-in-csit-release
 [2] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#known-issues
 [3] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/index.html
 [4] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/l2.html
 [5] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4.html
 [6] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip6.html
 [7] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/srv6.html
 [8] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4_tunnels.html
 [9] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vm_vhost.html
[10] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/container_memif.html
[11] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ipsec.html
[12] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vts.html
[13] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/throughput_speedup_multi_core/index.html
[14] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_latency/index.html
[15] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/comparisons/current_vs_previous_release.html
[16] https://docs.fd.io/csit/rls2005/report/detailed_test_results/vpp_performance_results/index.html
[17] https://docs.fd.io/csit/rls2005/report/test_configuration/vpp_performance_configuration/index.html
[18] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/csit_release_notes.html
[19] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_throughput_graphs/index.html
[20] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_latency/index.html
[21] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/comparisons/current_vs_previous_release.html
------------------------------------------------------------------------



    


Published: FD.io CSIT-2005 Release Report

Maciek Konstantynowicz (mkonstan)
 

Hi All,

FD.io CSIT-2005 report has been published on FD.io docs site:

https://docs.fd.io/csit/rls2005/report/

Many thanks to All in CSIT, VPP and wider FD.io community who
contributed and worked hard to make CSIT-2005 happen!

See below for pointers to specific sections in the report.

Welcome all comments, best by email to csit-dev@....

Cheers,
-Maciek

------------------------------------------------------------------------
Points of Note in the CSIT-2005 Report
------------------------------------------------------------------------
Indexed specific links listed at the bottom.

1. VPP release notes
a. Changes in CSIT-2005: [1]
b. Known issues: [2]

2. VPP performance - 64B/IMIX throughput graphs (selected NIC models):
a. Graphs explained: [3]
b. L2 Ethernet Switching: [4]
c. IPv4 Routing: [5]
d. IPv6 Routing: [6]
e. SRv6 Routing: [7]
f. IPv4 Tunnels: [8]
g. KVM VMs vhost-user: [9]
h. LXC/DRC Container Memif: [10]
e. IPsec IPv4 Routing: [11]
f. Virtual Topology System: [12]

3. VPP performance - multi-core and latency graphs:
a. Speedup Multi-Core: [13]
b. Latency: [14]

4. VPP performance comparisons
a. VPP-20.05 vs. VPP-20.01: [15]

5. VPP performance test details - all NICs:
a. Detailed results 64B IMIX 1518B 9kB: [16]
b. Configuration: [17]

DPDK Testpmd and L3fwd performance sections follow similar structure.

6. DPDK applications:
a. Release notes: [18]
b. DPDK performance - 64B throughput graphs: [19]
c. DPDK performance - latency graphs: [20]
d. DPDK performance - DPDK-20.02 vs. DPDK-19.08: [21]

Functional device tests (VPP_Device) are also included in the report.

Specific links within the report:

[1] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#changes-in-csit-release
[2] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#known-issues
[3] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/index.html
[4] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/l2.html
[5] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4.html
[6] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip6.html
[7] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/srv6.html
[8] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4_tunnels.html
[9] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vm_vhost.html
[10] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/container_memif.html
[11] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ipsec.html
[12] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vts.html
[13] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/throughput_speedup_multi_core/index.html
[14] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_latency/index.html
[15] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/comparisons/current_vs_previous_release.html
[16] https://docs.fd.io/csit/rls2005/report/detailed_test_results/vpp_performance_results/index.html
[17] https://docs.fd.io/csit/rls2005/report/test_configuration/vpp_performance_configuration/index.html
[18] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/csit_release_notes.html
[19] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_throughput_graphs/index.html
[20] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_latency/index.html
[21] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/comparisons/current_vs_previous_release.html
------------------------------------------------------------------------


Re: [vpp-dev] Replacing master/slave nomenclature

Kinsella, Ray <mdr@...>
 

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
Looping in the technical steering committee...

-----Original Message-----
From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
Sent: Thursday, July 2, 2020 7:02 PM
To: vpp-dev@...
Subject: [vpp-dev] Replacing master/slave nomenclature

Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.

Particularly problematic is the use of master/slave in bonding.
This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.

The IEEE and IETF are doing an across the board look at these terms in standards.




Re: [vpp-dev] Replacing master/slave nomenclature

Dave Barach
 

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@...>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
Looping in the technical steering committee...

-----Original Message-----
From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
Sent: Thursday, July 2, 2020 7:02 PM
To: vpp-dev@...
Subject: [vpp-dev] Replacing master/slave nomenclature

Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.

Particularly problematic is the use of master/slave in bonding.
This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.

The IEEE and IETF are doing an across the board look at these terms in standards.




Re: [vpp-dev] Replacing master/slave nomenclature

Dave Barach
 

Looping in the technical steering committee...

-----Original Message-----
From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
Sent: Thursday, July 2, 2020 7:02 PM
To: vpp-dev@...
Subject: [vpp-dev] Replacing master/slave nomenclature

Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.

Particularly problematic is the use of master/slave in bonding.
This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.

The IEEE and IETF are doing an across the board look at these terms in standards.


REMINDER: Community Input Required: Annual LFN Operations Survey

Brandon Wick
 

LFN Communities:

For the second year, LF Networking staff have pulled together an LFN Operations Survey, AKA "staff survey of the community." The goal is to solicit feedback from LFN community members to learn how you are engaging with projects, what you are experiencing, what the challenges are, and how the LFN staff can better support you. Your feedback is very important so please take a few minutes to share your thoughts with us. Responses are due by Friday, July 24th

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960


Upcoming LFN Webinars

Brandon Wick
 

LFN Community:

We've now confirmed 2 webinars in July from LFN Members Kubermatic and PANTHEON.tech:

July 7, 2020 | Why Edge Computing Requires Cloud Native Thinking | Bill Mulligan, Kubermatic | Learn More & Register

July 16, 2020 | Building CNFs with FD.io VPP and Network Service Mesh + VPP traceability in cloud-native deployments | Milan Lenčo & Pavel Kotúček, PANTHEON.tech | Learn More & Register

See all upcoming LFN webinars as well as past webinars available on demand here:


LFN members interested in hosting a webinar should read the guidelines and fill in the webinar submission form

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960


Community Input Required: Annual LFN Operations Survey

Brandon Wick
 

I'm not sure the hyperlink was working properly in my last email. Here again is the link to the Survey: https://www.surveymonkey.com/r/KGZNK5Z. Thanks all.

---------- Forwarded message ---------
From: Brandon Wick <bwick@...>
Date: Thu, Jul 2, 2020 at 1:29 PM
Subject: Community Input Required: Annual LFN Operations Survey
To:


LF Communities:

For the second year, LF Networking staff have pulled together an LFN Operations Survey, AKA "staff survey of the community." The goal is to solicit feedback from LFN community members to learn how you are engaging with projects, what you are experiencing, what the challenges are, and how the LFN staff can better support you. Your feedback is very important so please take a few minutes to share your thoughts with us. Responses are due by Friday, July 24th

Take the Survey here: https://www.surveymonkey.com/r/KGZNK5Z

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960


--

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960


Community Input Required: Annual LFN Operations Survey

Brandon Wick
 

LF Communities:

For the second year, LF Networking staff have pulled together an LFN Operations Survey, AKA "staff survey of the community." The goal is to solicit feedback from LFN community members to learn how you are engaging with projects, what you are experiencing, what the challenges are, and how the LFN staff can better support you. Your feedback is very important so please take a few minutes to share your thoughts with us. Responses are due by Friday, July 24th


Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960


OpenGrok Question

Vanessa Valderrama
 

LF is doing reviewing our INFRA inventory. We'd like to know if the
community actively uses OpenGrok?

Thank you,
Vanessa


Re: Cancelling this weeks TSC?

Edward Warnicke
 

Cancelled

Ed

On Tue, Jun 30, 2020 at 8:01 AM Joel Halpern <joel.halpern@...> wrote:

Fine with me.

Joel

 

From: tsc@... <tsc@...> On Behalf Of Dave Barach via lists.fd.io
Sent: Tuesday, June 30, 2020 6:06 AM
To: George Zhao <george.zhao@...>
Cc: Edward Warnicke <hagbard@...>; tsc@...; ray.kinsella@...
Subject: Re: [tsc] Cancelling this weeks TSC?

 

+1 let’s cancel...

Thanks... Dave



On Jun 30, 2020, at 4:21 AM, George Zhao <george.zhao@...> wrote:



Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?

 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed

 


Re: Cancelling this weeks TSC?

Joel Halpern
 

Fine with me.

Joel

 

From: tsc@... <tsc@...> On Behalf Of Dave Barach via lists.fd.io
Sent: Tuesday, June 30, 2020 6:06 AM
To: George Zhao <george.zhao@...>
Cc: Edward Warnicke <hagbard@...>; tsc@...; ray.kinsella@...
Subject: Re: [tsc] Cancelling this weeks TSC?

 

+1 let’s cancel...

Thanks... Dave



On Jun 30, 2020, at 4:21 AM, George Zhao <george.zhao@...> wrote:



Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?

 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed

 


Re: Cancelling this weeks TSC?

Dave Barach
 

+1 let’s cancel...

Thanks... Dave

On Jun 30, 2020, at 4:21 AM, George Zhao <george.zhao@...> wrote:


Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?
 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed



Re: Cancelling this weeks TSC?

George Zhao
 

Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?
 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed


Re: Cancelling this weeks TSC?

Ray Kinsella
 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed


Cancelling this weeks TSC?

Edward Warnicke
 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

Ed


Re: Absence

Edward Warnicke
 

All good!  Look forward to seeing you next week :)

Ed

On Thu, Jun 25, 2020 at 10:51 AM George Zhao <george.zhao@...> wrote:
Oops, my phone automatically turned off alarm for (Chinese) holidays, sorry I missed today's TSC.

thanks,
George

From: tsc@... <tsc@...> on behalf of Edward Warnicke via lists.fd.io <eaw=cisco.com@...>
Sent: Wednesday, June 24, 2020 9:28 AM
To: joel.halpern@... <joel.halpern@...>
Cc: tsc@... <tsc@...>
Subject: Re: [tsc] Absence
 
Thanks for letting us know :)

Ed

On Jun 24, 2020, at 10:12 AM, Joel Halpern via lists.fd.io <joel.halpern=ericsson.com@...> wrote:

I have a conflicting call tomorrow that I can not reschedule.  Sorry.
Yours,
Joel



Re: Absence

George Zhao
 

Oops, my phone automatically turned off alarm for (Chinese) holidays, sorry I missed today's TSC.

thanks,
George


From: tsc@... <tsc@...> on behalf of Edward Warnicke via lists.fd.io <eaw=cisco.com@...>
Sent: Wednesday, June 24, 2020 9:28 AM
To: joel.halpern@... <joel.halpern@...>
Cc: tsc@... <tsc@...>
Subject: Re: [tsc] Absence
 
Thanks for letting us know :)

Ed

On Jun 24, 2020, at 10:12 AM, Joel Halpern via lists.fd.io <joel.halpern=ericsson.com@...> wrote:

I have a conflicting call tomorrow that I can not reschedule.  Sorry.
Yours,
Joel