Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
On 26/06/2019, 18:44, "Stefano Stabellini" wrote: On Wed, 26 Jun 2019, Rich Persaud wrote: > > On Jun 26, 2019, at 06:45, Lars Kurth wrote: > > > > > > > > On 25/06/2019, 21:27, "Rich Persaud" wrote: > > > >> On Jun 25, 2019, at 16:17, Julien Grall wrote: > >> > >> Hi Rich, > >> > >> On 6/25/19 8:38 PM, Rich Persaud wrote: > On Jun 25, 2019, at 12:36, Lars Kurth wrote: > > Hi all: > please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one? > > > > We had quite a few additions to the agenda. One problem I have is that cryptpad history does not tell me who added an agenda item. We will have to manage this appropriately in the meeting. > > > >>> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g. > >>> METADATA > >>> - bug fix / improvement / refactor / cleanup / new feature > >>> - impacted Xen subsystems/components/features > >>> - targeted version of Xen > >>> - contributing person/org > >>> - relevance of patch series to the goals set by RM for the next Xen release > >>> - related patch series (with below status info) > >>> STATUS: > >>> - patch series version > >>> - date of patch series v1 > >>> - no responses received + ping count + days since submission + days since ping > >>> - reviewed with objections > >>> - reviewed without objections, awaiting ack > >>> - acked, awaiting merge > >>> From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context. > >> > >> While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers? > > > > Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees. > > > > This would only work if there was consensus on the priority amongst the key stake-holders. I believe that some limited prioritization has happened in the past, e.g. for some Arm related features for Xen 4.12 where, if I recall correctly you, Stefano and EPAM did this. > > > > Maybe we can trial this type of approach for a small number of series first. At the end of the day this is about queue management. Right now, when a new series comes in it ends up in one big queue (xen-devel@). Most complex series have to go through a series of gates (aka code reviews from different people) before they get applied and when a new version comes out the series ends up in the queue again: each reviewer today prioritizes their own review queues, where no-one else sees the prioritisation of other reviewers. Unless there is lot of spare review capacity (which there isn't) we essentially end up in grid-lock, with an ever-growing queue. We seem to have specific additional complexity in Xen because most recent series, typically involve a large number of reviewers. > > > > In theory, there are several ways to address this: > > * Queue management either by a set of agreed criteria which all reviewers follow or through some agreement about which series we actively try and shepherd through the gates > > * We have an additional issue that in many areas we have multiple reviewers/committers reviewing the same area of code, which also frequently leads to slow-downs, because the multiple reviewers/committers can disagree. We could look at a model where the reviewers/committers agree that one takes the lead on reviewing a specific series. We could try and streamline the ownership structure to create a clearer mapping. > > * The queues of each reviewer are somehow made public (assuming this is possible) and we hope that the system self-regulates. Not sure this will actually work > > > > The big problem I have is that mailing lists really don't lend themselves well to highlight what is going on. We have been grappling with this for years and things are getting worse, not better. > > > > In past community calls when we tried to do this with specific series, in practice we ended up discovering obstacles that were concerning a specific series, such as unexposed dependencies, lack of HW, specs against which to review being too complex, ... > > > > In any case, given that quite a few series were added to the agenda, maybe we shouldn't talk about process in the meeting, but see whether we can unblock those series. I am going to annotate some of the agenda items to highlight WHO needs to take action on items added > > > > We could have a wider discussion about
Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
On Wed, 26 Jun 2019, Rich Persaud wrote: > > On Jun 26, 2019, at 06:45, Lars Kurth wrote: > > > > > > > > On 25/06/2019, 21:27, "Rich Persaud" wrote: > > > >> On Jun 25, 2019, at 16:17, Julien Grall wrote: > >> > >> Hi Rich, > >> > >> On 6/25/19 8:38 PM, Rich Persaud wrote: > On Jun 25, 2019, at 12:36, Lars Kurth wrote: > > Hi all: > please add your agenda items. I had only ONE series which was > highlighted as needing attention from others. Is this seriously the only > one? > > > > We had quite a few additions to the agenda. One problem I have is that > > cryptpad history does not tell me who added an agenda item. We will have to > > manage this appropriately in the meeting. > > > >>> Proposed agenda item: in the absence of Jira tickets, would it be useful > >>> to have a list (e.g. generated by a script) with the lifecycle status of > >>> all outstanding patch series, e.g. > >>> METADATA > >>> - bug fix / improvement / refactor / cleanup / new feature > >>> - impacted Xen subsystems/components/features > >>> - targeted version of Xen > >>> - contributing person/org > >>> - relevance of patch series to the goals set by RM for the next Xen > >>> release > >>> - related patch series (with below status info) > >>> STATUS: > >>> - patch series version > >>> - date of patch series v1 > >>> - no responses received + ping count + days since submission + days since > >>> ping > >>> - reviewed with objections > >>> - reviewed without objections, awaiting ack > >>> - acked, awaiting merge > >>> From such a summary, patch series could be prioritized for review/triage > >>> in the community call, based on uniform criteria and project-wide context. > >> > >> While I think raising awareness of the stuck series is a good idea. I > >> still have some concern regarding the prioritization. Who is going to > >> consume the result of the discussion? Is it the maintainers? > > > > Anyone who typically answers the question raised by Lars in this thread, > > presumably a subset of call attendees. > > > > This would only work if there was consensus on the priority amongst the key > > stake-holders. I believe that some limited prioritization has happened in > > the past, e.g. for some Arm related features for Xen 4.12 where, if I > > recall correctly you, Stefano and EPAM did this. > > > > Maybe we can trial this type of approach for a small number of series > > first. At the end of the day this is about queue management. Right now, > > when a new series comes in it ends up in one big queue (xen-devel@). Most > > complex series have to go through a series of gates (aka code reviews from > > different people) before they get applied and when a new version comes out > > the series ends up in the queue again: each reviewer today prioritizes > > their own review queues, where no-one else sees the prioritisation of other > > reviewers. Unless there is lot of spare review capacity (which there isn't) > > we essentially end up in grid-lock, with an ever-growing queue. We seem to > > have specific additional complexity in Xen because most recent series, > > typically involve a large number of reviewers. > > > > In theory, there are several ways to address this: > > * Queue management either by a set of agreed criteria which all reviewers > > follow or through some agreement about which series we actively try and > > shepherd through the gates > > * We have an additional issue that in many areas we have multiple > > reviewers/committers reviewing the same area of code, which also frequently > > leads to slow-downs, because the multiple reviewers/committers can > > disagree. We could look at a model where the reviewers/committers agree > > that one takes the lead on reviewing a specific series. We could try and > > streamline the ownership structure to create a clearer mapping. > > * The queues of each reviewer are somehow made public (assuming this is > > possible) and we hope that the system self-regulates. Not sure this will > > actually work > > > > The big problem I have is that mailing lists really don't lend themselves > > well to highlight what is going on. We have been grappling with this for > > years and things are getting worse, not better. > > > > In past community calls when we tried to do this with specific series, in > > practice we ended up discovering obstacles that were concerning a specific > > series, such as unexposed dependencies, lack of HW, specs against which to > > review being too complex, ... > > > > In any case, given that quite a few series were added to the agenda, maybe > > we shouldn't talk about process in the meeting, but see whether we can > > unblock those series. I am going to annotate some of the agenda items to > > highlight WHO needs to take action on items added > > > > We could have a wider discussion about the process at the summit, as > > everyone who would need to be involved is at the summit. >
Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
> On Jun 26, 2019, at 06:45, Lars Kurth wrote: > > > > On 25/06/2019, 21:27, "Rich Persaud" wrote: > >> On Jun 25, 2019, at 16:17, Julien Grall wrote: >> >> Hi Rich, >> >> On 6/25/19 8:38 PM, Rich Persaud wrote: On Jun 25, 2019, at 12:36, Lars Kurth wrote: Hi all: please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one? > > We had quite a few additions to the agenda. One problem I have is that > cryptpad history does not tell me who added an agenda item. We will have to > manage this appropriately in the meeting. > >>> Proposed agenda item: in the absence of Jira tickets, would it be useful to >>> have a list (e.g. generated by a script) with the lifecycle status of all >>> outstanding patch series, e.g. >>> METADATA >>> - bug fix / improvement / refactor / cleanup / new feature >>> - impacted Xen subsystems/components/features >>> - targeted version of Xen >>> - contributing person/org >>> - relevance of patch series to the goals set by RM for the next Xen release >>> - related patch series (with below status info) >>> STATUS: >>> - patch series version >>> - date of patch series v1 >>> - no responses received + ping count + days since submission + days since >>> ping >>> - reviewed with objections >>> - reviewed without objections, awaiting ack >>> - acked, awaiting merge >>> From such a summary, patch series could be prioritized for review/triage in >>> the community call, based on uniform criteria and project-wide context. >> >> While I think raising awareness of the stuck series is a good idea. I still >> have some concern regarding the prioritization. Who is going to consume the >> result of the discussion? Is it the maintainers? > > Anyone who typically answers the question raised by Lars in this thread, > presumably a subset of call attendees. > > This would only work if there was consensus on the priority amongst the key > stake-holders. I believe that some limited prioritization has happened in the > past, e.g. for some Arm related features for Xen 4.12 where, if I recall > correctly you, Stefano and EPAM did this. > > Maybe we can trial this type of approach for a small number of series first. > At the end of the day this is about queue management. Right now, when a new > series comes in it ends up in one big queue (xen-devel@). Most complex series > have to go through a series of gates (aka code reviews from different people) > before they get applied and when a new version comes out the series ends up > in the queue again: each reviewer today prioritizes their own review queues, > where no-one else sees the prioritisation of other reviewers. Unless there is > lot of spare review capacity (which there isn't) we essentially end up in > grid-lock, with an ever-growing queue. We seem to have specific additional > complexity in Xen because most recent series, typically involve a large > number of reviewers. > > In theory, there are several ways to address this: > * Queue management either by a set of agreed criteria which all reviewers > follow or through some agreement about which series we actively try and > shepherd through the gates > * We have an additional issue that in many areas we have multiple > reviewers/committers reviewing the same area of code, which also frequently > leads to slow-downs, because the multiple reviewers/committers can disagree. > We could look at a model where the reviewers/committers agree that one takes > the lead on reviewing a specific series. We could try and streamline the > ownership structure to create a clearer mapping. > * The queues of each reviewer are somehow made public (assuming this is > possible) and we hope that the system self-regulates. Not sure this will > actually work > > The big problem I have is that mailing lists really don't lend themselves > well to highlight what is going on. We have been grappling with this for > years and things are getting worse, not better. > > In past community calls when we tried to do this with specific series, in > practice we ended up discovering obstacles that were concerning a specific > series, such as unexposed dependencies, lack of HW, specs against which to > review being too complex, ... > > In any case, given that quite a few series were added to the agenda, maybe we > shouldn't talk about process in the meeting, but see whether we can unblock > those series. I am going to annotate some of the agenda items to highlight > WHO needs to take action on items added > > We could have a wider discussion about the process at the summit, as everyone > who would need to be involved is at the summit. This has likely been raised before, but ... could the Xen community use Github/Gitlab PRs to reduce the overhead of managing a review queue? PR-based workflows have helped open-source projects to better utilize teams for review queue
Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
On 25/06/2019, 21:27, "Rich Persaud" wrote: > On Jun 25, 2019, at 16:17, Julien Grall wrote: > > Hi Rich, > > On 6/25/19 8:38 PM, Rich Persaud wrote: >>> On Jun 25, 2019, at 12:36, Lars Kurth wrote: >>> >>> Hi all: >>> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one? We had quite a few additions to the agenda. One problem I have is that cryptpad history does not tell me who added an agenda item. We will have to manage this appropriately in the meeting. >> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g. >> METADATA >> - bug fix / improvement / refactor / cleanup / new feature >> - impacted Xen subsystems/components/features >> - targeted version of Xen >> - contributing person/org >> - relevance of patch series to the goals set by RM for the next Xen release >> - related patch series (with below status info) >> STATUS: >> - patch series version >> - date of patch series v1 >> - no responses received + ping count + days since submission + days since ping >> - reviewed with objections >> - reviewed without objections, awaiting ack >> - acked, awaiting merge >> From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context. > > While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers? Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees. This would only work if there was consensus on the priority amongst the key stake-holders. I believe that some limited prioritization has happened in the past, e.g. for some Arm related features for Xen 4.12 where, if I recall correctly you, Stefano and EPAM did this. Maybe we can trial this type of approach for a small number of series first. At the end of the day this is about queue management. Right now, when a new series comes in it ends up in one big queue (xen-devel@). Most complex series have to go through a series of gates (aka code reviews from different people) before they get applied and when a new version comes out the series ends up in the queue again: each reviewer today prioritizes their own review queues, where no-one else sees the prioritisation of other reviewers. Unless there is lot of spare review capacity (which there isn't) we essentially end up in grid-lock, with an ever-growing queue. We seem to have specific additional complexity in Xen because most recent series, typically involve a large number of reviewers. In theory, there are several ways to address this: * Queue management either by a set of agreed criteria which all reviewers follow or through some agreement about which series we actively try and shepherd through the gates * We have an additional issue that in many areas we have multiple reviewers/committers reviewing the same area of code, which also frequently leads to slow-downs, because the multiple reviewers/committers can disagree. We could look at a model where the reviewers/committers agree that one takes the lead on reviewing a specific series. We could try and streamline the ownership structure to create a clearer mapping. * The queues of each reviewer are somehow made public (assuming this is possible) and we hope that the system self-regulates. Not sure this will actually work The big problem I have is that mailing lists really don't lend themselves well to highlight what is going on. We have been grappling with this for years and things are getting worse, not better. In past community calls when we tried to do this with specific series, in practice we ended up discovering obstacles that were concerning a specific series, such as unexposed dependencies, lack of HW, specs against which to review being too complex, ... In any case, given that quite a few series were added to the agenda, maybe we shouldn't talk about process in the meeting, but see whether we can unblock those series. I am going to annotate some of the agenda items to highlight WHO needs to take action on items added We could have a wider discussion about the process at the summit, as everyone who would need to be involved is at the summit. Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
> On Jun 25, 2019, at 16:17, Julien Grall wrote: > > Hi Rich, > > On 6/25/19 8:38 PM, Rich Persaud wrote: >>> On Jun 25, 2019, at 12:36, Lars Kurth wrote: >>> >>> Hi all: >>> please add your agenda items. I had only ONE series which was highlighted >>> as needing attention from others. Is this seriously the only one? >> Proposed agenda item: in the absence of Jira tickets, would it be useful to >> have a list (e.g. generated by a script) with the lifecycle status of all >> outstanding patch series, e.g. >> METADATA >> - bug fix / improvement / refactor / cleanup / new feature >> - impacted Xen subsystems/components/features >> - targeted version of Xen >> - contributing person/org >> - relevance of patch series to the goals set by RM for the next Xen release >> - related patch series (with below status info) >> STATUS: >> - patch series version >> - date of patch series v1 >> - no responses received + ping count + days since submission + days since >> ping >> - reviewed with objections >> - reviewed without objections, awaiting ack >> - acked, awaiting merge >> From such a summary, patch series could be prioritized for review/triage in >> the community call, based on uniform criteria and project-wide context. > > While I think raising awareness of the stuck series is a good idea. I still > have some concern regarding the prioritization. Who is going to consume the > result of the discussion? Is it the maintainers? Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees. Rich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
Hi Rich, On 6/25/19 8:38 PM, Rich Persaud wrote: On Jun 25, 2019, at 12:36, Lars Kurth wrote: Hi all: please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one? Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g. METADATA - bug fix / improvement / refactor / cleanup / new feature - impacted Xen subsystems/components/features - targeted version of Xen - contributing person/org - relevance of patch series to the goals set by RM for the next Xen release - related patch series (with below status info) STATUS: - patch series version - date of patch series v1 - no responses received + ping count + days since submission + days since ping - reviewed with objections - reviewed without objections, awaiting ack - acked, awaiting merge From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context. While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
> On Jun 25, 2019, at 12:36, Lars Kurth wrote: > > Hi all: > please add your agenda items. I had only ONE series which was highlighted as > needing attention from others. Is this seriously the only one? Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g. METADATA - bug fix / improvement / refactor / cleanup / new feature - impacted Xen subsystems/components/features - targeted version of Xen - contributing person/org - relevance of patch series to the goals set by RM for the next Xen release - related patch series (with below status info) STATUS: - patch series version - date of patch series v1 - no responses received + ping count + days since submission + days since ping - reviewed with objections - reviewed without objections, awaiting ack - acked, awaiting merge From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context. Rich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
Hi all: please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one? Regards Lars On 21/06/2019, 16:45, "Lars Kurth" wrote: Hi all, Please propose topics by either editing the running agenda document at https://cryptpad.fr/pad/#/2/pad/edit/V-JctV2vBlEnwliVLBlFLY7n/ or by replying to the mail. Note that currently I have * Nothing under: D) New Series / Series that need attention / Series that are important * A prep item for the developer summit proposed by Jan at the last meeting I also made some progress on the code of conduct topic and am about to send a mail to xen-devel@ Best Regards Lars == Dial-in Information == ## Meeting time 15:00 - 16:00 UTC Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=6=27=15=0=0=225=224=24=179=136=37=33 ## Dial in details Web: https://www.gotomeet.me/larskurth You can also dial in using your phone. Access Code: 906-886-965 China (Toll Free): 4008 811084 Germany: +49 692 5736 7317 Poland (Toll Free): 00 800 1124759 United Kingdom: +44 330 221 0088 United States: +1 (571) 317-3129 More phone numbers Australia: +61 2 9087 3604 Austria: +43 7 2081 5427 Argentina (Toll Free): 0 800 444 3375 Bahrain (Toll Free): 800 81 111 Belarus (Toll Free): 8 820 0011 0400 Belgium: +32 28 93 7018 Brazil (Toll Free): 0 800 047 4906 Bulgaria (Toll Free): 00800 120 4417 Canada: +1 (647) 497-9391 Chile (Toll Free): 800 395 150 Colombia (Toll Free): 01 800 518 4483 Czech Republic (Toll Free): 800 500448 Denmark: +45 32 72 03 82 Finland: +358 923 17 0568 France: +33 170 950 594 Greece (Toll Free): 00 800 4414 3838 Hong Kong (Toll Free): 30713169 Hungary (Toll Free): (06) 80 986 255 Iceland (Toll Free): 800 7204 India (Toll Free): 18002669272 Indonesia (Toll Free): 007 803 020 5375 Ireland: +353 15 360 728 Israel (Toll Free): 1 809 454 830 Italy: +39 0 247 92 13 01 Japan (Toll Free): 0 120 663 800 Korea, Republic of (Toll Free): 00798 14 207 4914 Luxembourg (Toll Free): 800 85158 Malaysia (Toll Free): 1 800 81 6854 Mexico (Toll Free): 01 800 522 1133 Netherlands: +31 207 941 377 New Zealand: +64 9 280 6302 Norway: +47 21 93 37 51 Panama (Toll Free): 00 800 226 7928 Peru (Toll Free): 0 800 77023 Philippines (Toll Free): 1 800 1110 1661 Portugal (Toll Free): 800 819 575 Romania (Toll Free): 0 800 410 029 Russian Federation (Toll Free): 8 800 100 6203 Saudi Arabia (Toll Free): 800 844 3633 Singapore (Toll Free): 18007231323 South Africa (Toll Free): 0 800 555 447 Spain: +34 932 75 2004 Sweden: +46 853 527 827 Switzerland: +41 225 4599 78 Taiwan (Toll Free): 0 800 666 854 Thailand (Toll Free): 001 800 011 023 Turkey (Toll Free): 00 800 4488 23683 Ukraine (Toll Free): 0 800 50 1733 United Arab Emirates (Toll Free): 800 044 40439 Uruguay (Toll Free): 0004 019 1018 Viet Nam (Toll Free): 122 80 481 First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items
Hi all, Please propose topics by either editing the running agenda document at https://cryptpad.fr/pad/#/2/pad/edit/V-JctV2vBlEnwliVLBlFLY7n/ or by replying to the mail. Note that currently I have * Nothing under: D) New Series / Series that need attention / Series that are important * A prep item for the developer summit proposed by Jan at the last meeting I also made some progress on the code of conduct topic and am about to send a mail to xen-devel@ Best Regards Lars == Dial-in Information == ## Meeting time 15:00 - 16:00 UTC Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=6=27=15=0=0=225=224=24=179=136=37=33 ## Dial in details Web: https://www.gotomeet.me/larskurth You can also dial in using your phone. Access Code: 906-886-965 China (Toll Free): 4008 811084 Germany: +49 692 5736 7317 Poland (Toll Free): 00 800 1124759 United Kingdom: +44 330 221 0088 United States: +1 (571) 317-3129 More phone numbers Australia: +61 2 9087 3604 Austria: +43 7 2081 5427 Argentina (Toll Free): 0 800 444 3375 Bahrain (Toll Free): 800 81 111 Belarus (Toll Free): 8 820 0011 0400 Belgium: +32 28 93 7018 Brazil (Toll Free): 0 800 047 4906 Bulgaria (Toll Free): 00800 120 4417 Canada: +1 (647) 497-9391 Chile (Toll Free): 800 395 150 Colombia (Toll Free): 01 800 518 4483 Czech Republic (Toll Free): 800 500448 Denmark: +45 32 72 03 82 Finland: +358 923 17 0568 France: +33 170 950 594 Greece (Toll Free): 00 800 4414 3838 Hong Kong (Toll Free): 30713169 Hungary (Toll Free): (06) 80 986 255 Iceland (Toll Free): 800 7204 India (Toll Free): 18002669272 Indonesia (Toll Free): 007 803 020 5375 Ireland: +353 15 360 728 Israel (Toll Free): 1 809 454 830 Italy: +39 0 247 92 13 01 Japan (Toll Free): 0 120 663 800 Korea, Republic of (Toll Free): 00798 14 207 4914 Luxembourg (Toll Free): 800 85158 Malaysia (Toll Free): 1 800 81 6854 Mexico (Toll Free): 01 800 522 1133 Netherlands: +31 207 941 377 New Zealand: +64 9 280 6302 Norway: +47 21 93 37 51 Panama (Toll Free): 00 800 226 7928 Peru (Toll Free): 0 800 77023 Philippines (Toll Free): 1 800 1110 1661 Portugal (Toll Free): 800 819 575 Romania (Toll Free): 0 800 410 029 Russian Federation (Toll Free): 8 800 100 6203 Saudi Arabia (Toll Free): 800 844 3633 Singapore (Toll Free): 18007231323 South Africa (Toll Free): 0 800 555 447 Spain: +34 932 75 2004 Sweden: +46 853 527 827 Switzerland: +41 225 4599 78 Taiwan (Toll Free): 0 800 666 854 Thailand (Toll Free): 001 800 011 023 Turkey (Toll Free): 00 800 4488 23683 Ukraine (Toll Free): 0 800 50 1733 United Arab Emirates (Toll Free): 800 044 40439 Uruguay (Toll Free): 0004 019 1018 Viet Nam (Toll Free): 122 80 481 First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
