[Xen-devel] Added workflow docs for git-series

[Lars Kurth]

See https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git-series
It solves some problems with git and makes managing series a little easier, but 
you still have to use autosquash
So, it's not perfect
Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 2/3] Add V section entry to allow identification of Xen MAINTAINERS file

[Lars Kurth]

This change provides sufficient information to allow get_maintainer.pl /
add_maintainers.pl scripts to be run on xen sister repositories such as
mini-os.git, osstest.git, etc

A suggested template for sister repositories of Xen is


This file follows the same conventions as outlined in
xen.git:MAINTAINERS. Please refer to the file in xen.git
for more information.

THE REST
M:  MAINTAINER1 
M:  MAINTAINER2 
L:  xen-devel@lists.xenproject.org
S:  Supported
F:  *
F:  */
V:  xen-maintainers-1


Signed-off-by: Lars Kurth 
---
 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 77413e0..bb3da43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -97,6 +97,9 @@ Descriptions of section entries:
  matches patches or files that contain one or more of the words
  printk, pr_info or pr_err
   One regex pattern per line.  Multiple K: lines acceptable.
+   V: Version identifier that must be under THE REST and follows
+  the format:
+  xen-maintainers-
 
 
 The meaning of nesting:
@@ -541,3 +544,4 @@ L:  xen-devel@lists.xenproject.org
 S: Supported
 F: *
 F: */
+V: xen-maintainers-1
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 1/3] Remove hardcoding from scripts/add_maintainers.pl

[Lars Kurth]

Instead of using a hardcoded location, inherit the
location from $0

Signed-off-by: Lars Kurth 
---
 scripts/add_maintainers.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index 09e9f66..5a6d0f6 100755
--- a/scripts/add_maintainers.pl
+++ b/scripts/add_maintainers.pl
@@ -26,9 +26,9 @@ sub insert ();
 sub hastag ($$);
 
 # Tool Variables
-my $get_maintainer  = "./scripts/get_maintainer.pl";
-
 my $tool = $0;
+my $get_maintainer = $tool;
+$get_maintainer =~ s/add_maintainers/get_maintainer/;
 my $usage = <https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 0/3] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

[Lars Kurth]

Use-case: Allow using both scripts on xen repositories such as
mini-os.git, osstest.git,

Assumptions: the repository contains a MAINTAINERS file that
follows the same conventions as the file in xen.git

A suggested template for sister repositories of Xen


This file follows the same conventions as outlined in
xen.git:MAINTAINERS. Please refer to the file in xen.git
for more information.

THE REST
M:  MAINTAINER1 
M:  MAINTAINER2 
L:  xen-devel@lists.xenproject.org
S:  Supported
F:  */
V:  xen-maintainers-1


Changes in v2:
* Remove debug message

Changes in v3:
* Split patch
* add_maintainers.pl: do not issue a warning
* add_maintainers.pl: introduce processing logic for V: tag
* MAINTAINERS: Add V: tag to file

Lars Kurth (3):
  Remove hardcoding from scripts/add_maintainers.pl
  Add V section entry to allow identification of Xen MAINTAINERS file
  Add logic to use V section entry in THE REST for identifying xen trees

 MAINTAINERS|  4 +++-
 scripts/add_maintainers.pl |  4 +--
 scripts/get_maintainer.pl  | 58 ---
 3 files changed, 42 insertions(+), 24 deletions(-)

base-commit: 6c9639a72f0ca3a9430ef75f375877182281fdef
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 3/3] Add logic to use V section entry in THE REST for identifying xen trees

[Lars Kurth]

Specifically:
* Move check until after the MAINTAINERS file has been read
* Add get_xen_maintainers_file_version() for check
* Remove top_of_tree as not needed any more
* Faiul with extended error message when used out of tree

Signed-off-by: Lars Kurth 
---
 scripts/get_maintainer.pl | 58 
 1 file changed, 36 insertions(+), 22 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 174dfb7..fe84a12 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -265,11 +265,6 @@ if ($email &&
 die "$P: Please select at least 1 email option\n";
 }
 
-if (!top_of_tree($xen_path)) {
-die "$P: The current directory does not appear to be "
-   . "a Xen source tree.\n";
-}
-
 ## Read MAINTAINERS for type/value pairs
 
 my @typevalue = ();
@@ -311,6 +306,16 @@ while (<$maint>) {
 }
 close($maint);
 
+# Check whether we have a V entry under the REST
+# hnd use it to get the file's version number
+my $maintainers_file_version = get_xen_maintainers_file_version();
+if (!$maintainers_file_version) {
+die "$P: the MAINTAINERS file ".
+ "in the current directory does not appear to be from ".
+ "the xen.git source tree or a sister tree.\n\n".
+ "A 'V: xen-maintainers-' entry under THE REST ".
+ "is needed to identify a Xen MAINTAINERS file.\n\n";
+}
 
 #
 # Read mail address map
@@ -564,6 +569,32 @@ sub range_has_maintainer {
 return 0;
 }
 
+sub get_xen_maintainers_file_version {
+my $tvi = find_first_section();
+
+while ($tvi < @typevalue) {
+my $start = find_starting_index($tvi);
+my $end = find_ending_index($tvi);
+my $i;
+
+for ($i = $start; $i < $end; $i++) {
+my $line = $typevalue[$i];
+   if ($line =~ m/^V:\s*(.*)/) {
+my $type = $1;
+# Note that get_maintainer_role() requires processing
+# of more of the file. So do it directly
+if ($typevalue[$start] eq "THE REST") {
+if ($line =~ m/xen-maintainers-(.*)/) {
+return $1;
+}
+}
+   }
+}
+$tvi = $end + 1;
+}
+return 0;
+}
+
 sub get_maintainers {
 %email_hash_name = ();
 %email_hash_address = ();
@@ -867,23 +898,6 @@ Notes:
 EOT
 }
 
-sub top_of_tree {
-my ($xen_path) = @_;
-
-if ($xen_path ne "" && substr($xen_path,length($xen_path)-1,1) ne "/") {
-   $xen_path .= "/";
-}
-if ((-f "${xen_path}COPYING")
-&& (-f "${xen_path}MAINTAINERS")
-&& (-f "${xen_path}Makefile")
-&& (-d "${xen_path}docs")
-&& (-f "${xen_path}CODING_STYLE")
-&& (-d "${xen_path}xen")) {
-   return 1;
-}
-return 0;
-}
-
 sub parse_email {
 my ($formatted_email) = @_;
 
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 3/3] Add logic to use V section entry in THE REST for identifying xen trees

[Lars Kurth]

On 02/09/2019, 09:08, "Jan Beulich"  wrote:

On 30.08.2019 22:09, Lars Kurth wrote:
> Specifically:
> * Move check until after the MAINTAINERS file has been read
> * Add get_xen_maintainers_file_version() for check
> * Remove top_of_tree as not needed any more
> * Faiul with extended error message when used out of tree
    > 
    > Signed-off-by: Lars Kurth 

Just a couple of nits (my Perl is far from good enough to actually
give an ack):

> @@ -311,6 +306,16 @@ while (<$maint>) {
>  }
>  close($maint);
>  
> +# Check whether we have a V entry under the REST
> +# hnd use it to get the file's version number

s/hnd/and/ 

I really shouldn't send patches out in a rush. Thank you!

> @@ -564,6 +569,32 @@ sub range_has_maintainer {
>  return 0;
>  }
>  
> +sub get_xen_maintainers_file_version {
> +my $tvi = find_first_section();
> +
> +while ($tvi < @typevalue) {
> +my $start = find_starting_index($tvi);
> +my $end = find_ending_index($tvi);
> +my $i;
> +
> +for ($i = $start; $i < $end; $i++) {
> +my $line = $typevalue[$i];
> + if ($line =~ m/^V:\s*(.*)/) {

A hard tab looks to have slipped in here.

> +my $type = $1;

This variable looks to be unused, but perhaps its declaration
has some side effect?

It is really unneeded
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

On 02/09/2019, 16:49, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> I attached a redline version of both the original (based on the LF events 
CoC) and a redline version based on the covenant given the constraints we 
agreed. Aka
> [1] Xen CoC Contributor Covenant baseline (redline).pdf 
> [2] Xen CoC LF events baseline (redline).pdf
> 
> I minimized changes to [2]. 

I like both of these.  I would be happy to adopt either.  I prefer the
Contributor Covenant based version.


I have two comments.  The first is very minor:

The LF Events one has one different section title.  Instead of
Enforcement
it has
What To Do If You Witness Or Are Subject To Unacceptable
Behavior 
which is unwieldy but better in other ways - more positive and
constructive.  I'm not sure if there is a happy middle ground.
I am happy to adopt either version with either title.  I mention it in
case anyone has better ideas etc.

I am also altogether happier with the Contributor Covenant, but maybe 
with a few additional changes such as changing some titles and some
of the modifications outlined earlier.

My second comment is more substantial.  It should not be regarded as a
blocker, but I would like to see it addressed either now or after CoC
adoption.

The root issue is the difficult one of what to do about possible
involvement in abuse by members of the conduct@ address.

I would like to see two changes: firstly, we should publish the list
of people that the conduct alias goes to.  The CoC should contain a
reference to the place where this can be found.  "The membership of
the conduct@ alias is publicly documented in [location]".

That is entirely sensible. I think the best place would be to record this
in the document. We should probably start with a shortlist of people 
and include it in the next version and get it all approved in one go

Secondly, we should explicitly provide a route for someone who
distrusts member(s) of conduct@.  How about:

  If you have concerns about any of the members of the conduct@ alias,
  you are welcome to contact precisely the Conduct Team member(s) of
  your choice.

That is entirely fine with me.

The team should be large and diverse enough that this is a practically
useful recommendation, but it should not be unwieldy.

I was thinking of 2-3 maybe 4 people. Can those leadership team members
who are willing to step up reply to me privately or in this thread. I am 
assuming 
that I will be a member of conduct@, but I am also willing to step aside
if it helps.

Regardless of this, I think I have enough to send out a concrete proposal
for further review

Best Regards
Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Please propose agenda items for Thursday's community call

[Lars Kurth]

Folks,
I have not gotten around to draft an agenda yet. Please reply to this thread 
with possible agenda items. I will reply to this thread with meeting invite and 
details as usual
Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 3/3] Add logic to use V section entry in THE REST for identifying xen trees

[Lars Kurth]

Specifically:
* Move check until after the MAINTAINERS file has been read
* Add get_xen_maintainers_file_version() for check
* Remove top_of_tree as not needed any more
* Fail with extended error message when used out of tree

Signed-off-by: Lars Kurth 
---
 scripts/get_maintainer.pl | 57 
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 174dfb7..2e661f4 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -265,11 +265,6 @@ if ($email &&
 die "$P: Please select at least 1 email option\n";
 }
 
-if (!top_of_tree($xen_path)) {
-die "$P: The current directory does not appear to be "
-   . "a Xen source tree.\n";
-}
-
 ## Read MAINTAINERS for type/value pairs
 
 my @typevalue = ();
@@ -311,6 +306,16 @@ while (<$maint>) {
 }
 close($maint);
 
+# Check whether we have a V entry under the REST
+# and use it to get the file's version number
+my $maintainers_file_version = get_xen_maintainers_file_version();
+if (!$maintainers_file_version) {
+die "$P: the MAINTAINERS file ".
+ "in the current directory does not appear to be from ".
+ "the xen.git source tree or a sister tree.\n\n".
+ "A 'V: xen-maintainers-' entry under THE REST ".
+ "is needed to identify a Xen MAINTAINERS file.\n\n";
+}
 
 #
 # Read mail address map
@@ -564,6 +569,31 @@ sub range_has_maintainer {
 return 0;
 }
 
+sub get_xen_maintainers_file_version {
+my $tvi = find_first_section();
+
+while ($tvi < @typevalue) {
+my $start = find_starting_index($tvi);
+my $end = find_ending_index($tvi);
+my $i;
+
+for ($i = $start; $i < $end; $i++) {
+my $line = $typevalue[$i];
+if ($line =~ m/^V:\s*(.*)/) {
+# Note that get_maintainer_role() requires processing
+# of more of the file. So do it directly
+if ($typevalue[$start] eq "THE REST") {
+if ($line =~ m/xen-maintainers-(.*)/) {
+return $1;
+}
+}
+   }
+}
+$tvi = $end + 1;
+}
+return 0;
+}
+
 sub get_maintainers {
 %email_hash_name = ();
 %email_hash_address = ();
@@ -867,23 +897,6 @@ Notes:
 EOT
 }
 
-sub top_of_tree {
-my ($xen_path) = @_;
-
-if ($xen_path ne "" && substr($xen_path,length($xen_path)-1,1) ne "/") {
-   $xen_path .= "/";
-}
-if ((-f "${xen_path}COPYING")
-&& (-f "${xen_path}MAINTAINERS")
-&& (-f "${xen_path}Makefile")
-&& (-d "${xen_path}docs")
-&& (-f "${xen_path}CODING_STYLE")
-&& (-d "${xen_path}xen")) {
-   return 1;
-}
-return 0;
-}
-
 sub parse_email {
 my ($formatted_email) = @_;
 
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 2/3] Add V section entry to allow identification of Xen MAINTAINERS file

[Lars Kurth]

This change provides sufficient information to allow get_maintainer.pl /
add_maintainers.pl scripts to be run on xen sister repositories such as
mini-os.git, osstest.git, etc

A suggested template for sister repositories of Xen is


This file follows the same conventions as outlined in
xen.git:MAINTAINERS. Please refer to the file in xen.git
for more information.

THE REST
M:  MAINTAINER1 
M:  MAINTAINER2 
L:  xen-devel@lists.xenproject.org
S:  Supported
F:  *
F:  */
V:  xen-maintainers-1


Signed-off-by: Lars Kurth 
Acked-by: Jan Beulich 
---
 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 77413e0..bb3da43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -97,6 +97,9 @@ Descriptions of section entries:
  matches patches or files that contain one or more of the words
  printk, pr_info or pr_err
   One regex pattern per line.  Multiple K: lines acceptable.
+   V: Version identifier that must be under THE REST and follows
+  the format:
+  xen-maintainers-
 
 
 The meaning of nesting:
@@ -541,3 +544,4 @@ L:  xen-devel@lists.xenproject.org
 S: Supported
 F: *
 F: */
+V: xen-maintainers-1
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 0/3] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

[Lars Kurth]

Use-case: Allow using both scripts on xen repositories such as
mini-os.git, osstest.git,

Assumptions: the repository contains a MAINTAINERS file that
follows the same conventions as the file in xen.git

A suggested template for sister repositories of Xen


This file follows the same conventions as outlined in
xen.git:MAINTAINERS. Please refer to the file in xen.git
for more information.

THE REST
M:  MAINTAINER1 
M:  MAINTAINER2 
L:  xen-devel@lists.xenproject.org
S:  Supported
F:  *
F:  */
V:  xen-maintainers-1


Changes in v2:
* Remove debug message

Changes in v3:
* Split patch
* add_maintainers.pl: do not issue a warning
* add_maintainers.pl: introduce processing logic for V: tag
* MAINTAINERS: Add V: tag to file

Changes in v4:
* Removed tabs and fixed typo
* Removed unused variable

Lars Kurth (3):
  Remove hardcoding from scripts/add_maintainers.pl
  Add V section entry to allow identification of Xen MAINTAINERS file
  Add logic to use V section entry in THE REST for identifying xen trees

 MAINTAINERS|  4 +++-
 scripts/add_maintainers.pl |  4 +--
 scripts/get_maintainer.pl  | 57 +++
 3 files changed, 41 insertions(+), 24 deletions(-)

base-commit: 6c9639a72f0ca3a9430ef75f375877182281fdef
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 1/3] Remove hardcoding from scripts/add_maintainers.pl

[Lars Kurth]

Instead of using a hardcoded location, inherit the
location from $0

Signed-off-by: Lars Kurth 
---
 scripts/add_maintainers.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index 09e9f66..5a6d0f6 100755
--- a/scripts/add_maintainers.pl
+++ b/scripts/add_maintainers.pl
@@ -26,9 +26,9 @@ sub insert ();
 sub hastag ($$);
 
 # Tool Variables
-my $get_maintainer  = "./scripts/get_maintainer.pl";
-
 my $tool = $0;
+my $get_maintainer = $tool;
+$get_maintainer =~ s/add_maintainers/get_maintainer/;
 my $usage = <https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Please propose agenda items for Thursday's community call

[Lars Kurth]

On 04/09/2019, 13:35, "Jan Beulich"  wrote:

On 03.09.2019 20:37, Lars Kurth wrote:
> I have not gotten around to draft an agenda yet. Please reply to
> this thread with possible agenda items. I will reply to this
> thread with meeting invite and details as usual

Well, on one hand I would have two topics:

- the pending AMD maintainership changes
- the various pending follow-ups of mine to XSAs 275 ... 294

But otoh I won't be able to attend more than the first half of
the meeting tomorrow (and even this overlaps with an internal
event here), possibly less depending on weather.

I will make sure that your items are covered first
Regards
Lars
 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC

[Lars Kurth]

Hi all,

the proposed agenda is in 
https://cryptpad.fr/pad/#/2/pad/edit/xwUTm6b5f5ijPTQcF9IFgkBg/ and you can edit 
to add items
Alternatively, you can reply to this mail directly
Agenda items appreciated ASAP: please put your name besides items if you edit 
the document

Apologies for dropping the ball on this one, I forgot to add the CC list to the 
earlier mail I sent

Regards
Lars
P.S.: If you want to be added or removed from the CC list please reply privately

== Dial-in Information ==

## Meeting time
15:00 - 16:00 UTC
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=9&day=5&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=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] [Poll] Please vote on date options for next year's Developer Summit (closes Wednesday, September 11)

[Lars Kurth]

Hi all,

we started planning next year’s Developer Summit, which is due to be in Europe. 
We have a venue in Bucharest, Romania secured but are still working through the 
details. As we are early, we do have several date options: so I wanted to give 
you a choice to vote, such that we end up with a date that works best for you

Note that the Linux Foundation event schedule for next year is VERY different 
from that of past years. Open Source Summit NA will be in the week of June 22nd 
and thus we are not considering an event 1 week before and 1 week after.

I did add the week post 4th of July: this could be a problem for some people in 
the US, but I left the slot in regardless. 

The poll is at 
https://docs.google.com/forms/d/e/1FAIpQLSd_kB2w5XgW6aNqknV_7Bh96hGHDas3JWdYuXQWpTEWFn58ag/viewform
 and closes Wednesday, September 11

Best Regards
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] Import v1.4 of Contributor Covenant CoC

[Lars Kurth]

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 code-of-conduct.md | 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 code-of-conduct.md

diff --git a/code-of-conduct.md b/code-of-conduct.md
new file mode 100644
index 000..81b217c
--- /dev/null
+++ b/code-of-conduct.md
@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, 
body
+size, disability, ethnicity, sex characteristics, gender identity and 
expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies 
when
+an individual is representing the project or its community in public spaces.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event. Representation of
+a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an 
incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], 
version 1.4,
+available at 
https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/2] Code of Conduct (based on Contributor Covenant v1.4)

[Lars Kurth]

This series proposes a concrete version of the Xen Project
CoC based on v1.4 of the Contributor Covenant. See [1]

It also reflects the discussion in [2] and some private
discussions on IRC to identify initial members of the Xen
Project???s CoC team.

For convenence of review and in line with other policy documents
I created a git repository at [3]. This series can be found at [5].

The series is incomplete in that it does not yet contain the document
on positive behavior: this will be based on [4]. My intention is to
use a lightwight process based on
* Documentation to set expectations, share tips and best practices - with the
hope that people in the community reflect occasionally on how they are doing
against these (or are maybe prompted by peers to do so)
* A safe back-channel to ask for advice when a conversation becomes inefficient,
unactionable, is unfriendly, ... with a view to recover it
* Arbitration in cases where there is some friction amongst participants in a
discussion, which was not resolvable by any of the before. After all, when this
happens there is a risk that a working relationship gets negatively impacted. It
is actually in the interest of each participant to improve to avoid friction,
stress, etc.

I hope that we can approve the series without the first part, but I do not mind
if people feel this needs to be done in one go.

[1] https://www.contributor-covenant.org/version/1/4/code-of-conduct.md
[2] https://xen.markmail.org/thread/56ao2gyhpltqmrew
[3] http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=summary
[4] 
https://www.slideshare.net/xen_com_mgr/xpdds19-keynote-patch-review-for-nonmaintainers-george-dunlap-citrix-systems-uk-ltd
[5] 
http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=shortlog;h=refs/heads/CoC-v1

Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org


Lars Kurth (2):
  Import v1.4 of Contributor Covenant CoC
  Xen Project Code of Conduct

-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] Xen Project Code of Conduct

[Lars Kurth]

Specific changes to the baseline:
* Replace list of positive behaviors with link to separate process
* Replace maintainers with project leadership
  (except in our pledge where maintainers is more appropriate)
* Add 'of all sub-projects' to clarify scope of CoC
* Rename Enforcement
* Replace "project team" with "Conduct Team members"
* Add e-mail alias
* Add section on contacting individual Conduct Team members
* Add section on Conduct Team members

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 code-of-conduct.md | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/code-of-conduct.md b/code-of-conduct.md
index 81b217c..ee751a7 100644
--- a/code-of-conduct.md
+++ b/code-of-conduct.md
@@ -1,4 +1,4 @@
-# Contributor Covenant Code of Conduct
+# Xen Project Code of Conduct
 
 ## Our Pledge
 
@@ -11,14 +11,10 @@ appearance, race, religion, or sexual identity and 
orientation.
 
 ## Our Standards
 
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+We believe that a Code of Conduct can help create a harassment-free 
environment,
+but is not sufficient to create a welcoming environment on its own: guidance on
+creating a welcoming environment, how to communicate in an effective and 
friendly
+way, etc. can be found [here]: TODO-INSERT-URL.
 
 Examples of unacceptable behavior by participants include:
 
@@ -33,11 +29,11 @@ Examples of unacceptable behavior by participants include:
 
 ## Our Responsibilities
 
-Project maintainers are responsible for clarifying the standards of acceptable
+Project leadership team members are responsible for clarifying the standards 
of acceptable
 behavior and are expected to take appropriate and fair corrective action in
 response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or
+Project leadership team members have the right and responsibility to remove, 
edit, or
 reject comments, commits, code, wiki edits, issues, and other contributions
 that are not aligned to this Code of Conduct, or to ban temporarily or
 permanently any contributor for other behaviors that they deem inappropriate,
@@ -45,26 +41,40 @@ threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies within all project spaces, and it also applies 
when
+This Code of Conduct applies within all project spaces of all sub-projects, 
and it also applies when
 an individual is representing the project or its community in public spaces.
 Examples of representing a project or community include using an official
 project e-mail address, posting via an official social media account, or acting
 as an appointed representative at an online or offline event. Representation of
-a project may be further defined and clarified by project maintainers.
+a project may be further defined and clarified by the project leadership.
 
-## Enforcement
+## What to do if you witness or are subject to unacceptable behavior
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
+reported by contacting Conduct Team members at cond...@xenproject.org. All
 complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
+is deemed necessary and appropriate to the circumstances. Conduct Team members 
are
 obligated to maintain confidentiality with regard to the reporter of an 
incident.
 Further details of specific enforcement policies may be posted separately.
 
-Project maintainers who do not follow or enforce the Code of Conduct in good
+If you have concerns about any of the members of the conduct@ alias,
+you are welcome to contact precisely the Conduct Team member(s) of
+your choice.
+
+Project leadership team members who do not follow or enforce the Code of 
Conduct in good
 faith may face temporary or permanent repercussions as determined by other
 members of the project's leadership.
 
+## Conduct Team members
+Conduct Team members are project leadership team members from any
+sub-project. The current list of Conduct Team members is:
+* Lars Kurth 
+* George Dunlap 
+* Ian Jackson 
+
+Conduct Team members are changed by proposing a change to this document,
+posted on all sub-project lists, followed by a formal global vote as outlined 
[here]: https://xenproject.org/developers/governance/#project-decisions
+
 ## Attribution
 
 T

Re: [Xen-devel] [PATCH 0/2] Code of Conduct (based on Contributor Covenant v1.4)

[Lars Kurth]

On 04/09/2019, 19:12, "Lars Kurth"  wrote:

This series proposes a concrete version of the Xen Project
CoC based on v1.4 of the Contributor Covenant. See [1]

Apologies for the badly formatted patch. It seems the normal instructions do 
not work when using it on virgin git repository and I didn't realize that -N2 
strips the 1/2, 2/2

The distribution list is so wide, as this affects all sub-projects

Lars 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC

[Lars Kurth]

On 05/09/2019, 08:41, "Rich Persaud"  wrote:

> On Sep 5, 2019, at 03:19, Jan Beulich  wrote:
> 
> Forgive me asking, but why is this put up as an agenda item here?
> IMO this is the kind of thing where you would send a proposal and
> request feedback by email first, and put it up as an agenda item
> here only if it got stalled there. (Apologies if I've overlooked
> such a stalled thread.)

If Xen community call topics are limited to escalations of xen-devel 
threads, then a new thread can be created for this topic. Xen community calls 
have also provided real-time, interactive feedback on candidate proposals, 
along with guidance on areas which need documentation before a formal proposal 
is made to xen-devel.   Such agenda items are typically covered after all 
series and priority topics have been addressed.

I don't mind having items such these on the agenda and to be fair have added 
similar items onto the agenda in the past.
Clearly, they are forward looking [like an RFC], for which reason I tend to add 
them to the end of an agenda if there is a busy schedule

Personally, on this specific item, it is not really clear what the questions 
are.  In other words: is this about UUIDS/domain ids only, or is there 
something else. 

Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC

[Lars Kurth]

On 05/09/2019, 08:50, "Jan Beulich"  wrote:

On 05.09.2019 09:41, Rich Persaud wrote:
> If Xen community call topics are limited to escalations of xen-devel 
threads, then a new thread can be created for this topic. Xen community calls 
have also provided real-time, interactive feedback on candidate proposals, 
along with guidance on areas which need documentation before a formal proposal 
is made to xen-devel.   Such agenda items are typically covered after all 
series and priority topics have been addressed.

I'll certainly listen to what others think, but I have to confess that
on such prior instances I was already on the edge of requesting that
time not be spent in such a way. Please recall that calls, other than
mails, take everybody's time, and exactly at the same time. Therefore
my personal opinion is that topics on calls should be limited to items
which cannot be resolved by other means, or which are certain to need
(almost) everybody's attention right away.

I disagree with you on this one. 

So yes, it is true that a call costs everyone time. But it's a fixed cost once 
per month
*  Something experimental could be posted on the list and it may take everyone 
more time to read and respond than a 5 minute early discussion on the call
* Also, of course everyone has the option to drop out or not attend a call 
based on the agenda
* If we had more urgent stuff to discuss all the time and we would have to 
displace urgent discussions to cover discussions which can wait, I may agree 
with you, but this is not currently the case

I will look at the agenda though and re-structure it in such a way that this is 
clear

IMPORTANT: I had a few additions to the agenda, but do not know WHO added 
these. I believe one was Juergen. Who added the items related to MA Youngs 
patches? And if you add series to discuss can you please add URLs or message IDs

Regards
Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC

[Lars Kurth]

On 05/09/2019, 09:33, "Juergen Gross"  wrote:

On 05.09.19 10:14, Andrew Cooper wrote:
> On 05/09/2019 08:49, Lars Kurth wrote:
>> On 05/09/2019, 08:41, "Rich Persaud"  wrote:
>>
>>  > On Sep 5, 2019, at 03:19, Jan Beulich  wrote:
>>  >
>>  > Forgive me asking, but why is this put up as an agenda item here?
>>  > IMO this is the kind of thing where you would send a proposal and
>>  > request feedback by email first, and put it up as an agenda item
>>  > here only if it got stalled there. (Apologies if I've overlooked
>>  > such a stalled thread.)
>>  
>>  If Xen community call topics are limited to escalations of 
xen-devel threads, then a new thread can be created for this topic. Xen 
community calls have also provided real-time, interactive feedback on candidate 
proposals, along with guidance on areas which need documentation before a 
formal proposal is made to xen-devel.   Such agenda items are typically covered 
after all series and priority topics have been addressed.
>>  
>> I don't mind having items such these on the agenda and to be fair have 
added similar items onto the agenda in the past.
>> Clearly, they are forward looking [like an RFC], for which reason I tend 
to add them to the end of an agenda if there is a busy schedule
>>
>> Personally, on this specific item, it is not really clear what the 
questions are.  In other words: is this about UUIDS/domain ids only, or is 
there something else.
> 
> Requiring something to be blocked on xen-devel before we discuss it on
> the call is monumentally short sighted, and off-putting for contributors.
> 
> In this case, it is very definitely not the first time this problem has
> been raised, as it is an XSA shaped elephant in the room.  Its no secret
> that id wraps cause problems, and while our security policy doesn't
> comment on the matter, it also doesn't say "warning - stuff *will* break
> in weird, wonderful, and security-relevant ways when domid's wrap".
> 
> The order of the agenda is important, and I don't think this should be
> at the top, but even if we only end up with 2 minutes to discuss it,
> then so be it.  (2 minutes of talking can still be far more valuable
> than a weeks worth of emailing.)
> 
> What is not acceptable is suggesting that it should be veto'd simply
> because it is perceived to be a very fresh idea/query.

I still think it would help if a short high level design would be posted
on xen-devel first.

I think that is a valid point and I agree. In the past when we had similar
discussions often the outcome was not that clear and due to the nature of
the calls the discussions were also not well reflected in the notes.

So, there is an argument, that discussions typically are more productive when
there is the possibility for some preparation or an e-mail thread to refer to.

Lars   


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC

[Lars Kurth]

> We can defer the xenstoreless name service topic to the October monthly call.
>
> For today's call, can we discuss the previously posted high-level design for 
> unification of the domB RFC with dom0less, as "domB mode" for
> disaggregation of Xen's dom0?
>
> - domB mode for dom0less (July 2019):  https://lists.gt.net/xen/devel/557782
> - domB RFC (June 2018):  https://lists.gt.net/xen/devel/519367

I had seen this too late. Apologies
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] docs/sphinx: todo/wishlist

[Lars Kurth]

On 22/07/2019, 20:21, "Andrew Cooper"  wrote:

a.k.a. (at least in this form) Andrew's "work which might be offloadable to
someone else" list.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
CC: Lars Kurth 
CC: Paul Durrant 
CC: Roger Pau Monné 

RFC for obvious reasons.

A rendered version of this can be found at:
https://andrewcoop-xen.readthedocs.io/en/docs-wishlist/misc/wishlist.html

During XenSummit in Chicago, it was expressed several times that having some
todo lists would be a benefit, to help coordinate work in related areas.

Here is an attempt to start one.  For now, it covers one single
item (xenstored's use of non-stable APIs) to get some feedback about the
general approach.  I have plenty to get stuck into in Xen itself if this way
of expressing them isn't deemed unacceptable.

As for the wishlist itself, I think it is important that it be restricted to
concrete actions (i.e. already partially groomed, if you speak agile), which
are identified problems, and suggested fixes.

In particular, I don't think it is appropriate to devolve into a bullet 
point
list of new features, or tasks like "document $whotsit".  It should be
restricted to things which are real problems, on existing systems, which 
have
some forward plan of action.  That way, any developer should be able to
cross-reference at least at a high level, and see if there are areas of
overlapping work, or whether a slightly tweaked approach might be suitable 
for
multiple areas.

Anyway - thoughts from the peanut gallery?

Hi Andy, sorry I had missed this. I think this is a good idea and worth 
experimenting with.

Regarding Rich's comment, I thought we already agreed that we can use a CC, but 
we have not decided how to do this in practical terms as we may be hoovering up 
content that in the past may have been published as GPL

Lars
 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [ANNOUNCE] Minutes for September 5th Community Call

[Lars Kurth]

Minutes are at 
https://cryptpad.fr/pad/#/2/pad/view/kpV4XxFWKjAF1fbIckIV87BVTRVRFlL913YWaFD0waI/embed/present/
 and attached
Lars



2019-09 Community Call.pdf
Description: 2019-09 Community Call.pdf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria for checking in core scheduling series

[Lars Kurth]

On 06/09/2019, 12:09, "George Dunlap"  wrote:

There was a discussion on the community call about the core scheduling
series being developed by Juergen Gross [1].  The conclusion can be
summarized as follows:

* We normally wait to check in series until they are quite good -- all
the i's dotted and all the t's crossed

* This is for several reasons; primarily because once code gets checked
in, it rarely gets looked at again.  In particular, there's nothing
stopping the submitter from neglecting to do important clean-ups, in
spite of their best intentions; leaving the maintainer or the rest of
the community to do it.

* However, for particularly long, complicated series like the core
scheduling series, this can have significant downsides.  Rebasing a
60-patch branch regularly is a lot of churn for little value; and core
parts of the series which are mostly complete are currently only getting
sporadic dev testing rather than the wide range of testing they would
get from being in staging.

* XenServer and SuSE are both long-term community members with a strong
incentive to maintain and improve the feature; so the risk of the
feature being left for the community to maintian is relatively now.

With all those things in mind, the conclusion was to lower the
"check-in" threshold from what it normally is, in order to allow the
series to be checked in in the near future, in enough time at least for
the "default off" to be well-tested by the 4.13 release.

The criteria we sketched out were:

* All the patches still need appropriate Ack / R-b's

* There should be reason to believe that the series will have little to
no impact on "thread mode" (threads being the unit of scheduling; i.e.,
the status quo)

WRT the second point, apparently XenServer have been testing the series
regularly for some time, and are satisfied from a testing perspective
that there is no significant degradation for the series when in "thread
mode".

So this would really be a recommendation / license to the various
maintainers involved; primarily Dario, I think (since I probably won't
have time to review the series).

No decisions are official until discussed on xen-devel; so the decision
will not be considered official until a few days have passed without
objection.  And of course, if anyone at the meeting had a different
understanding of what was said, or has something to add, please do so.

I believe the following people were on the community call and did NOT have 
objections when asked
Sergey, Jan, Juergen, Andrew, George, Roger, Christopher Clark, Daniel P Smith, 
Rich (list may be incomplete)

We are asking because key people have not been on the community call

Regards
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Xen Project Code of Conduct

[Lars Kurth]

On 06/09/2019, 16:10, "Roger Pau Monne"  wrote:

On Wed, Sep 04, 2019 at 07:12:18PM +0100, Lars Kurth wrote:
[...]
> +## Conduct Team members
> +Conduct Team members are project leadership team members from any
> +sub-project. The current list of Conduct Team members is:
> +* Lars Kurth 
> +* George Dunlap 
> +* Ian Jackson 
> +
> +Conduct Team members are changed by proposing a change to this document,
> +posted on all sub-project lists, followed by a formal global vote as 
outlined [here]: https://xenproject.org/developers/governance/#project-decisions

Could you break the above line to match the existing line length of
the document?

Sure, I can do this in the next revision

I intentionally didn't do line breaks on most changes to make sure that the 
differences can be seen

Also, we will probably never publish this content anywhere but on the main 
website (as html generated from the MD)

Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [Vote] XCP-ng subproject proposal

[Lars Kurth]

Hello everyone,

Olivier had posted an RFC for this proposal on xen-devel@- see 
https://xen.markmail.org/thread/ermnrb3ps3okvnjr 
 

The proposal also has been discussed by the Advisory Board and was approved

However, for the proposal to fully pass the proposal must be run by past all 
mature subproject, which are Hypervisors, Windows PV Drivers and XAPI (see 
https://xenproject.org/developers/governance/#project-decisions 
). People 
listed under Project team visible on the right columns of following pages can 
vote
* https://xenproject.org/developers/teams/xen-hypervisor/ 
 - already voted: Jan, 
Ian, Wei, George
* https://xenproject.org/developers/teams/windows-pv-drivers/ 

* https://xenproject.org/developers/teams/xen-api/ 


The RFC proposal has passed the Hypervisor team with 4/8 votes (see 
https://xen.markmail.org/thread/ermnrb3ps3okvnjr 
), but more support would be 
appreciated

The proposal is attached below. Please vote before next Tuesday

Best Regards
Lars

# XCP-ng proposal

## The Project

XCP-ng is a turn-key virtualization platform based on the Xen Hypervisor, using 
existing Xen Project tools (XAPI). It's built from Xenserver source, improved 
and maintained by both passionate individuals and companies. The result is a 
completely free and Open Source solution available for everyone.

Thanks to a very successful Kickstarter campaign as well as backing from 
various companies, the project doesn't require any further funds and isn't 
seeking monetary contributions.

We believe forming a Xen sub-project within the Linux Foundation has the 
potential to bring further companies and contributors into the Xen Project as a 
whole, as well as demonstrate our dedication to open source. XCP-ng has already 
displayed its ability to draw new users into the Xen virtualization ecosystem. 
For new users, utilizing Xen from scratch can be daunting. XCP-ng offers a way 
to solve this problem by drawing end-users more closely into the Xen Project 
and providing an easy route for prospective Xen users to get started with Xen. 
This is an area where Xen has been trailing KVM for a long time. Hosting XCP-ng 
within the Xen Project provides a route to level the playing field. It would 
also enable the Xen Project to leverage XCP-ng success stories for the benefit 
of the Xen Project as a whole.

## The Mission

Our goal is to continue development of XCP-ng while building a large community 
of contributors to XCP-ng. We also expect an increase of contributions to XAPI 
as well as the Xen Project. Through large community involvement and 
contributions we have already turned XCP-ng into a stable hypervisor platform 
that is used in small and large enterprise deployments.

## Upstream first, fully Open Source

Vates and XCP-ng have started to work with a number of academic organizations 
with the aim to fund and develop feature improvements and new features that 
benefit the whole Xen Project ecosystem (including the Hypervisor and XAPI). We 
follow an upstream first philosophy, which is possible because of the fast 
release cycle of XCP-ng and expect to become a long-term contributor to XAPI 
and the Hypervisor project.

Besides contributions, we believe that an XCP-ng which is part of the Xen 
Project will deliver other benefits:

* Bring passionate and verbal XCP-ng users closer to the Xen Project
* Bring more publicity to the Xen Project: currently we have the XCP-ng blog, 
newsletter and success stories, which we are willing to share with the Xen 
Project

With an incredibly active forum, IRC, and github, we are always looking for 
more contributors to the project. We also believe in giving back to the open 
source community via contributions to upstream projects, and we believe 
becoming a Xen Project member will help in our ability to do so. To further our 
dedication to open source, Vates SAS, the company with the most active 
contributions to XCP-ng currently, is in the process of becoming a Linux 
Foundation member.

## How we differ from existing platforms

Our vision is to maintain XCP-ng as a complete easy-to-use hypervisor solution 
similar to existing full-stack solutions. Where we differ is our dedication to 
the open source mindset. We have no licensing system or license restrictions, 
all pieces of the platform are free to use. Simultaneously, we encourage 
community involvement and have merged many community contributions already.

## Infrastructure

The infrastructure will be primarily managed by Vates, with multiple companies 
in partnership (mainly hosting companies owning DC real estate). Access and 
resources can be given for people interested in becoming maint

Re: [Xen-devel] [PATCH v4 2/3] Add V section entry to allow identification of Xen MAINTAINERS file

[Lars Kurth]

On 10/09/2019, 16:31, "Julien Grall"  wrote:

Hi,

Actually, I have one question about the template (my ack still stands).

On 9/10/19 4:18 PM, Julien Grall wrote:
> Hi Lars,
> 
> On 9/4/19 12:30 PM, Lars Kurth wrote:
>> This change provides sufficient information to allow get_maintainer.pl /
>> add_maintainers.pl scripts to be run on xen sister repositories such as
>> mini-os.git, osstest.git, etc
>>
>> A suggested template for sister repositories of Xen is
>>
>> 
>> This file follows the same conventions as outlined in
>> xen.git:MAINTAINERS. Please refer to the file in xen.git
>> for more information.
>>
>> THE REST
>> M:  MAINTAINER1 
>> M:  MAINTAINER2 
>> L:  xen-devel@lists.xenproject.org

I was under the impression that the scripts would be used for Unikraft. 
If so, do we expect them to CC xen-devel everytime?

In that case, the template has to be adapted. I was mainly thinking of 
XTF, OSSTEST, livepatch-build-tools. If it were used say for minios
(which I think it should)  the L: field would obviously need changing
 
Once this series is through, I will submit maintainer files for all those
projects making sure that they have the right L: field.

If the answer is no, then we will probably want to add_maintainers.pl.

I basically dropped the original patch for Unikraft as nobody has responded.
I was not planning to pick this up, unless someone from Unikraft runs with it 

Regards
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [livepatch-build-tools] Add V: entry to maintainers

[Lars Kurth]

Usage of get_maintainers.pl now requires the V: entry under
THE REST to identify a MAINTAINERS file in one of the Xen
trees. See [1]

[1] lists.xenproject.org/archives/html/xen-devel/2019-09/threads.html#00263

Signed-off-by: Lars Kurth 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index de2aedb..b92a8fe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9,3 +9,4 @@ L:  xen-devel@lists.xenproject.org
 S: Supported
 F: *
 F: */
+V: xen-maintainers-1
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH OSSTEST] Introduce a MAINTAINERS file

[Lars Kurth]

Rationale: this will allow us to use get_maintainer.pl /
add_maintainers.pl scripts from xen.git

Signed-off-by: Lars Kurth 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 MAINTAINERS

diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 000..de2aedb
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,11 @@
+This file follows the same conventions as outlined in
+xen.git:MAINTAINERS. Please refer to the file in xen.git
+for more information.
+
+THE REST
+M:Ian Jackson 
+L:xen-devel@lists.xenproject.org
+S:Supported
+F:*
+F:*/
+V:xen-maintainers-1
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH XTF] Introduce a MAINTAINERS file

[Lars Kurth]

Rationale: this will allow us to use get_maintainer.pl /
add_maintainers.pl scripts from xen.git

Signed-off-by: Lars Kurth 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 MAINTAINERS

diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 000..0ef9b5e
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,11 @@
+iThis file follows the same conventions as outlined in
+xen.git:MAINTAINERS. Please refer to the file in xen.git
+for more information.
+
+THE REST
+M: Andrew Cooper 
+L: xen-devel@lists.xenproject.org
+S: Supported
+F: *
+F: */
+V: xen-maintainers-1
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] create-diff-object: more precisely identify .rodata sections

[Lars Kurth]

On 18/09/2019, 11:44, "Wieczorkiewicz, Pawel"  wrote:

> On 18. Sep 2019, at 12:41, Ian Jackson  wrote:
> 
> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely 
identify .rodata sections"):
>> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
>>> $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
>> 
>> '-d' only tells you where the patches files are. The script will look up 
for the 
>> MAINTAINERS file in the current directory.
> 
> Hmmm.  I wonder if we could detect this situation somehow.  This will
> be a common user error I think.

I don't think it is possible to detect that situation as git format-patch does 
not tell you which tree a patch was generated from.

I should have looked twice before sending the patch out. But, what would be 
very helpful for me
is additional option to the add_maintainers.pl script like: -m ./MAINTAINERS

In my view this is only really an issue if you create a patch or series and 
then do something else before finalizing and sending the patch, otherwise I 
would have tripped over this myself. But of course, if you work on multiple 
series at the same time that is an easy mistake to make.

I would expect that the most common directory structure for people is to have a 
directory structure such as
~/code/xen.git
~/code/livepatch-build-tools
...
~/code/patches 

and that people switch between git directories. Looking at the code, I should 
be able to add a -m option, which would work out the directory in which 
MAINTAINERS is, then switch to it, do the processing and switch back to where 
we started from.

However, this would only really work, if there was a strong recommendation in 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Using_add_maintainers.pl_.28or_get_maintainer.pl.29_from_outside_of_xen.git
 telling people to use -m $path/MAKEFILE when working on multiple directories

Would that work?

Lars
 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] create-diff-object: more precisely identify .rodata sections

[Lars Kurth]

On 18/09/2019, 12:15, "Julien Grall"  wrote:

Hi Ian,

On 18/09/2019 11:41, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely 
identify .rodata sections"):
>> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
>>> $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
>>
>> '-d' only tells you where the patches files are. The script will look up 
for the
>> MAINTAINERS file in the current directory.
> 
> Hmmm.  I wonder if we could detect this situation somehow.  This will
> be a common user error I think.
I think it would be possible for patch modifying file. We could check 
whether 
the file modified exist in the repo. Though, I am not sure how difficult it 
would be to implement.

That might be doable, but won't be easy as I will essentially need to parse the 
patch
And it won't be reliable. 

The only workable way of doing this may be to have a strong convention
that requires to use the [REPONAME PATCH] via --subject-prefix when generating 
the 
patch and for add_maintainers.pl to verify this somehow based on the current
directory and the patches.

We already have strong conventions in some cases, e.g. for OSSTEST we always use
[OSSTEST PATCH]. This would potentially be helpful for the CI loop plans aso. 

Assuming there is a git config setting for --subject-prefix then this could be 
made 
to work. I could add a section under [1] to document the convention with the
appropriate git command. We could include a script (e.g. 
xen.git:scrips/git-setup) 
which does this based on the repo name automatically.

Any views?

Lars

[1] 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_the_patches_to_the_list
 
 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] create-diff-object: more precisely identify .rodata sections

[Lars Kurth]

On 18/09/2019, 12:27, "Wieczorkiewicz, Pawel"  wrote:



> On 18. Sep 2019, at 13:19, Julien Grall  wrote:
> 
> Hi Pawel,
> 
> On 18/09/2019 11:44, Wieczorkiewicz, Pawel wrote:
>>> On 18. Sep 2019, at 12:41, Ian Jackson  wrote:
>>> 
>>> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely 
identify .rodata sections"):
 On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
> $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
 
 '-d' only tells you where the patches files are. The script will look 
up for the
 MAINTAINERS file in the current directory.
>>> 
>>> Hmmm.  I wonder if we could detect this situation somehow.  This will
>>> be a common user error I think.
>>> 
>> I should have looked twice before sending the patch out. But, what would 
be very helpful for me
>> is additional option to the add_maintainers.pl script like: -m 
./MAINTAINERS
> 
> Well the filename will always be the same, so at best you will provide 
redundant information.

Not if I create a git-ignored symlink to the other repo.

You could also put add_maintainers.pl on the path

Until I implement a fix,  I fixed the docs. See
* 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Using_add_maintainers.pl_.28or_get_maintainer.pl.29_from_outside_of_xen.git
 
* 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Setting_that_help_save_you_time
 

Lars
 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] add_maintainers.pl issues / "canonical" subject prefixes for CI v2 (was Re: [PATCH] create-diff-object: more precisely identify .rodata sections)

[Lars Kurth]

+Ross 
+ Doug

On 19/09/2019, 10:30, "Julien Grall"  wrote:

Hi Lars,

On 18/09/2019 13:14, Lars Kurth wrote:
> 
> 
> On 18/09/2019, 12:15, "Julien Grall"  wrote:
> 
>  Hi Ian,
>  
>  On 18/09/2019 11:41, Ian Jackson wrote:
>  > Julien Grall writes ("Re: [PATCH] create-diff-object: more 
precisely identify .rodata sections"):
>  >> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
>  >>> $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
>  >>
>  >> '-d' only tells you where the patches files are. The script will 
look up for the
>  >> MAINTAINERS file in the current directory.
>  >
>  > Hmmm.  I wonder if we could detect this situation somehow.  This 
will
>  > be a common user error I think.
>  I think it would be possible for patch modifying file. We could 
check whether
>  the file modified exist in the repo. Though, I am not sure how 
difficult it
>  would be to implement.
>  
> That might be doable, but won't be easy as I will essentially need to 
parse the patch
> And it won't be reliable.
> 
> The only workable way of doing this may be to have a strong convention
> that requires to use the [REPONAME PATCH] via --subject-prefix when 
generating the
> patch and for add_maintainers.pl to verify this somehow based on the 
current
> directory and the patches.
> 
> We already have strong conventions in some cases, e.g. for OSSTEST we 
always use
> [OSSTEST PATCH]. This would potentially be helpful for the CI loop plans 
aso.
> 
> Assuming there is a git config setting for --subject-prefix then this 
could be made
> to work. I could add a section under [1] to document the convention with 
the
> appropriate git command. We could include a script (e.g. 
xen.git:scrips/git-setup)
> which does this based on the repo name automatically.

I saw a conversation on IRC about this. But it is not clear if there was 
any 
conclusion?

Ian was going to write down what we discussed

My only slight concern about tagging by default is the length of the 
subject, 
when directly receiving from xen-devel (i.e. not CCed), the subject is 
already 
[xen-devel][PATCH XX/XX]. I am assuming the tag will not be dropped so it 
will 
appear on the mailing list. For repo such as LIVEPATCH-BUILD, this would 
end up 
to lengthy prefix.

That is true: I think we do need to have a formal discussion with vote about 
this at some point. 

And we can certainly shorten some of those "canonical" subject prefixes. 
But having gone back to the early patches posted for LIVEPATCH-BUILD by Konrad 
and Ross, they were either
[LIVEPATCH-BUILD-TOOLS] or [LIVEPATCH-BUILD-TOOLS PATCH]

My view at this stage, is that I am merely documenting existing conventions 
The exception is "XEN PATCH"

For people who are just starting to read this conversation, see
* 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Settings_that_help_save_you_time
* 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Subject_Prefix 
which I added yesterday

We do need to solve this somehow for two reasons:
1. Fool proofing add_maintainers.pl tool [although this is relatively minor]
2. More importantly we need to support the CI v2 capability (aka triggering 
tests for patches posted to xen-devel@)

On 1: Ian had an idea, which I think I understood correctly, but am not 100% 
sure. So waiting for him to write it down

On 2: We need a way to identify which tree a patch or patch series is for, such 
that any CI infra can perform the right action, in light of
* QEMU, LINUX, ... patches are posted to xen-devel@ today
* Patches for multiple xen-repos are posted to xen-devel@ today

But maybe we should move this into a new thread. In the meantime I changed the 
subject line

Lars



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Moving next week's community call to Thu 10th

[Lars Kurth]

Hi all,
because many of us will be at the Platform Security Summit next week, I propose 
to move the community call to Thu 10th at the usual time
Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 4/6] Add Code Review Guide

[Lars Kurth]

From: Lars Kurth 

This document highlights what reviewers such as maintainers and committers look
for when reviewing code. It sets expectations for code authors and provides
a framework for code reviewers.

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 code-review-guide.md | 125 +++
 1 file changed, 125 insertions(+)
 create mode 100644 code-review-guide.md

diff --git a/code-review-guide.md b/code-review-guide.md
new file mode 100644
index 000..8639431
--- /dev/null
+++ b/code-review-guide.md
@@ -0,0 +1,125 @@
+# Code Review Guide
+
+This document highlights what reviewers such as maintainers and committers look
+for when reviewing your code. It sets expectations for code authors and 
provides
+a framework for code reviewers.
+
+This document does **not cover** the following topics:
+* [Communication Best Practice](communication-practice.md)
+* [Resolving Disagreement](resolving-disagreement.md)
+* [Patch Submission 
Workflow](https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches)
+* [Managing Patch Submission with 
Git](https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git)
+
+## What we look for in Code Reviews
+When performing a code review, reviewers typically look for the following 
things
+
+### Is the change necessary to accomplish the goals?
+* Is it clear what the goals are?
+* Do we need to make a change, or can the goals be met with existing
+  functionality?
+
+### Architecture / Interface
+* Is this the best way to solve the problem?
+* Is this the right part of the code to modify?
+* Is this the right level of abstraction?
+* Is the interface general enough? Too general? Forward compatible?
+
+### Functionality
+* Does it do what it’s trying to do?
+* Is it doing it in the most efficient way?
+* Does it handle all the corner / error cases correctly?
+
+### Maintainability / Robustness
+* Is the code clear? Appropriately commented?
+* Does it duplicate another piece of code?
+* Does the code make hidden assumptions?
+* Does it introduce sections which need to be kept **in sync** with other 
sections?
+* Are there other **traps** someone modifying this code might fall into?
+
+**Note:** Sometimes you will work in areas which have identified 
maintainability
+and/or robustness issues. In such cases, maintainers may ask you to make 
additional
+changes, such that your submitted code does not make things worse or point you
+to other patches are already being worked on.
+
+### System properties
+In some areas of the code, system properties such as
+* Code size
+* Performance
+* Scalability
+* Latency
+* Complexity
+* &c
+are also important during code reviews.
+
+### Style
+* Comments, carriage returns, **snuggly braces**, &c
+* See 
[CODING_STYLE](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=CODING_STYLE)
+  and 
[tools/libxl/CODING_STYLE](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/CODING_STYLE)
+* No extraneous whitespace changes
+
+### Documentation and testing
+* If there is pre-existing documentation in the tree, such as man pages, design
+  documents, etc. a contributor may be asked to update the documentation 
alongside
+  the change. Documentation is typically present in the
+  [docs](https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=docs) folder.
+* When adding new features that have an impact on the end-user,
+  a contributor should include an update to the
+  [SUPPORT.md](https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=docs) file.
+  Typically, more complex features require several patch series before it is 
ready to be
+  advertised in SUPPORT.md
+* When adding new features, a contributor may be asked to provide tests or
+  ensure that existing tests pass
+
+ Testing for the Xen Project Hypervisor
+Tests are typically located in one of the following directories
+* **Unit tests**: 
[tools/tests](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=tree;f=tools/tests)
+or 
[xen/test](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=tree;f=xen/test)
+  Unit testing is hard for a system like Xen and typically requires building a 
subsystem of
+  your tree. If your change can be easily unit tested, you should consider 
submitting tests
+  with your patch.
+* **Build and smoke test**: see [Xen GitLab 
CI](https://gitlab.com/xen-project/xen/pipelines)
+  Runs build tests for a combination of various distros and compilers against 
changes
+  committed to staging. Developers can join as members and test their 
development
+  branches **before** submitting a patch.
+* **XTF tests** (microkernel-based tests): see 
[XTF](https://xenbits.xenproject.org/docs/xtf/)
+  XTF has been designed to test interactions between your software and 
hardware.
+  It is a very useful tool for testing low level functionalit

[Xen-devel] [PATCH v2 5/6] Add guide on Communication Best Practice

[Lars Kurth]

From: Lars Kurth 

This guide covers the bulk on Best Practice related to code review
It primarily focusses on code review interactions
It also covers how to deal with Misunderstandings and Cultural
Differences

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 communication-practice.md | 410 ++
 1 file changed, 410 insertions(+)
 create mode 100644 communication-practice.md

diff --git a/communication-practice.md b/communication-practice.md
new file mode 100644
index 000..db9a5ef
--- /dev/null
+++ b/communication-practice.md
@@ -0,0 +1,410 @@
+# Communication Best Practice
+
+This guide provides communication Best Practice that helps you in
+* Using welcoming and inclusive language
+* Keeping discussions technical and actionable
+* Being respectful of differing viewpoints and experiences
+* Being aware of your own and counterpart’s communication style and culture
+* Show empathy towards other community members
+
+## Code reviews for **reviewers** and **patch authors**
+
+Before embarking on a code review, it is important to remember that
+* A poorly executed code review can hurt the contributors feeling, even when a 
reviewer
+  did not intend to do so. Feeling defensive is a normal reaction to a 
critique or feedback.
+  A reviewer should be aware of how the pitch, tone, or sentiment of their 
comments
+  could be interpreted by the contributor. The same applies to responses of an 
author
+  to the reviewer.
+* When reviewing someone's code, you are ultimately looking for issues. A good 
code
+  reviewer is able to mentally separate finding issues from articulating code 
review
+  comments in a constructive and positive manner: depending on your 
personality this
+  can be **difficult** and you may need to develop a technique that works for 
you.
+* As software engineers we like to be proud of the solutions we came up with. 
This can
+  make it easy to take another people’s criticism personally. Always remember 
that it is
+  the code that is being reviewed, not you as a person.
+* When you receive code review feedback, please be aware that we have reviewers
+  from different backgrounds, communication styles and cultures. Although we 
all trying
+  to create a productive, welcoming and agile environment, we do not always 
succeed.
+
+### Express appreciation
+As the nature of code review to find bugs and possible issues, it is very easy 
for
+reviewers to get into a mode of operation where the patch review ends up being 
a list
+of issues, not mentioning what is right and well done. This can lead to the 
code
+submitter interpreting your feedback in a negative way.
+
+The opening of a code review provides an opportunity to address this and also 
sets the
+tone for the rest of the code review. Starting **every** review on a positive 
note, helps
+set the tone for the rest of the review.
+
+For an initial patch, you can use phrases such as
+> Thanks for the patch
+> Thanks for doing this
+
+For further revisions within a review, phrases such as
+> Thank you for addressing the last set of changes
+
+If you believe the code was good, it is good practice to highlight this by 
using phrases
+such as
+> Looks good, just a few comments
+> The changes you have made since the last version look good
+
+If you think there were issues too many with the code to use one of the 
phrases,
+you can still start on a positive note, by for example saying
+> I think this is a good change
+> I think this is a good feature proposal
+
+It is also entirely fine to highlight specific changes as good. The best place 
to
+do this, is at top of a patch, as addressing code review comments typically 
requires
+a contributor to go through the list of things to address and an in-lined 
positive
+comment is likely to break that workflow.
+
+You should also consider, that if you review a patch of an experienced
+contributor phrases such as *Thanks for the patch* could come across as
+patronizing, while using *Thanks for doing this* is less likely to be 
interpreted
+as such.
+
+Appreciation should also be expressed by patch authors when asking for 
clarifications
+to a review or responding to questions. A simple
+> Thank you for your feedback
+> Thank you for your reply
+> Thank you XXX!
+
+is normally sufficient.
+
+### Avoid opinion: stick to the facts
+The way how a reviewer expresses feedback, has a big impact on how the author
+perceives the feedback. Key to this is what we call **stick to the facts**.  
The same is
+true when a patch author is responding to a comment from a reviewer.
+
+One of our maintainers has been studying Mandarin for several years and has 
come
+across the most strongly-worded dictionary entry
+[he has ever seen](https://youtu.be/ehZvBmrLRwg?t=834). This exampl

[Xen-devel] [PATCH v2 6/6] Added Resolving Disagreement

[Lars Kurth]

From: Lars Kurth 

This guide provides Best Practice on identifying and resolving
common classes of disagreement

Signed-off-by: Lars Kurth 
--
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 resolving-disagreement.md | 146 ++
 1 file changed, 146 insertions(+)
 create mode 100644 resolving-disagreement.md

diff --git a/resolving-disagreement.md b/resolving-disagreement.md
new file mode 100644
index 000..19aedbe
--- /dev/null
+++ b/resolving-disagreement.md
@@ -0,0 +1,146 @@
+# Resolving Disagreement
+
+This guide provides Best Practice on resolving disagreement, such as
+* Gracefully accept constructive criticism
+* Focus on what is best for the community
+* Resolve differences in opinion effectively
+
+## Theory: Paul Graham's hierarchy of disagreement
+Paul Graham proposed a **disagreement hierarchy** in a 2008 essay 
+**[How to Disagree](http://www.paulgraham.com/disagree.html)**, putting types 
of
+arguments into a seven-point hierarchy and observing that *moving up the
+disagreement hierarchy makes people less mean, and will make most of them 
happier*.
+Graham also suggested that the hierarchy can be thought of as a pyramid, as 
the 
+highest forms of disagreement are rarer.
+
+| ![Graham's Hierarchy of 
Disagreemen](https://upload.wikimedia.org/wikipedia/commons/a/a3/Graham%27s_Hierarchy_of_Disagreement-en.svg)
 |
+| *A representation of Graham's hierarchy of disagreement from 
[Loudacris](http://www.createdebate.com/user/viewprofile/Loudacris) modified by 
[Rocket000](https://en.wikipedia.org/wiki/User:Rocket000)* |
+
+In the context of the Xen Project we strive to **only use the top half** of 
the hierarchy.
+**Name-calling** and **Ad hominem** arguments are not acceptable within the Xen
+Project.
+
+## Issue: Scope creep
+
+One thing which occasionally happens during code review is that a code reviewer
+asks or appears to ask the author of patch to implement additional 
functionality.
+
+This could take for example the form of
+> Do you think it would be useful for the code to do XXX? 
+> I can imagine a user wanting to do YYY (and XXX would enable this)
+
+That potentially adds additional work for the code author, which they may not 
have
+the time to perform. It is good practice for authors to consider such a 
request in terms of
+* Usefulness to the user
+* Code churn, complexity or impact on other system properties
+* Extra time to implement and report back to the reviewer
+
+If you believe that the impact/cost is too high, report back to the reviewer. 
To resolve
+this, it is advisable to
+* Report your findings
+* And then check whether this was merely an interesting suggestion, or 
something the
+reviewer feels more strongly about
+
+In the latter case, there are typically several common outcomes
+* The **author and reviewer agree** that the suggestion should be implemented
+* The **author and reviewer agree** that it may make sense to defer 
implementation
+* The **author and reviewer agree** that it makes no sense to implement the 
suggestion
+
+The author of a patch would typically suggest their preferred outcome, for 
example
+> I am not sure it is worth to implement XXX
+> Do you think this could be done as a separate patch in future?
+
+In cases, where no agreement can be found, the best approach would be to get an
+independent opinion from another maintainer or the project's leadership team.
+
+## Issue: [Bikeshedding](https://en.wiktionary.org/wiki/bikeshedding)
+
+Occasionally discussions about unimportant but easy-to-grasp issues can lead to
+prolonged and unproductive discussion. The best way to approach this is to
+try and **anticipate** bikeshedding and highlight it as such upfront. However, 
the
+format of a code review does not always lend itself well to this approach, 
except
+for highlighting it in the cover letter of a patch series.
+
+However, typically Bikeshedding issues are fairly easy to recognize in a code 
review,
+as you will very quickly get different reviewers providing differing opinions. 
In this case
+it is best for the author or a reviewer to call out the potential bikeshedding 
issue using
+something like
+
+> Looks we have a bikeshedding issue here
+> I think we should call a quick vote to settle the issue
+
+Our governance provides the mechanisms of [informal 
votes](https://xenproject.org/developers/governance/#informal-votes-or-surveys) 
or
+[lazy voting](https://xenproject.org/developers/governance/#lazyconsensus) 
which lend
+themselves well to resolve such issues.
+
+## Issue: Small functional issues
+
+The most common area of disagreements which happen in code reviews, are 
differing
+opinions on whether small functional issues in a patch series have to be 
resolved or
+not before the code is ready to be submitted. Such d

[Xen-devel] [PATCH v2 3/6] Add Communication Guide

[Lars Kurth]

From: Lars Kurth 

This document is a portal page that lays out our gold standard,
best practices for some common situations and mechanisms to help
resolve issues that can have a negative effect on our community.

Detail is covered in subsequent documents

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 communication-guide.md | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 communication-guide.md

diff --git a/communication-guide.md b/communication-guide.md
new file mode 100644
index 000..4bcf440
--- /dev/null
+++ b/communication-guide.md
@@ -0,0 +1,67 @@
+# Communication Guide
+
+We believe that our [Code of Conduct] (code-of-conduct.md) can help create a
+harassment-free environment, but is not sufficient to create a welcoming
+environment on its own. We can all make mistakes: when we do, we take
+responsibility for them and try to improve.
+
+This document lays out our gold standard, best practices for some common
+situations and mechanisms to help resolve issues that can have a
+negative effect on our community.
+
+## Goal
+
+We want a productive, welcoming and agile community that can welcome new
+ideas in a complex technical field which is able to reflect on and improve how 
we
+work.
+
+## Communication & Handling Differences in Opinions
+
+Examples of behavior that contributes to creating a positive environment
+include:
+* Use welcoming and inclusive language
+* Keep discussions technical and actionable
+* Be respectful of differing viewpoints and experiences
+* Be aware of your own and counterpart’s communication style and culture
+* Gracefully accept constructive criticism
+* Focus on what is best for the community
+* Show empathy towards other community members
+* Resolve differences in opinion effectively
+
+## Getting Help
+
+When developing code collaboratively, technical discussion and disagreements
+are unavoidable. Our contributors come from different countries and cultures,
+are driven by different goals and take pride in their work and in their point
+of view. This invariably can lead to lengthy and unproductive debate,
+followed by indecision, sometimes this can impact working relationships
+or lead to other issues that can have a negative effect on our community.
+
+To minimize such issue, we provide a 3-stage process
+* Self-help as outlined in this document
+* Ability to ask for an independent opinion or help in private
+* Mediation between parties which disagree. In this case a neutral community
+  member assists the disputing parties resolve the issues or will work with the
+  parties such that they can improve future interactions.
+
+If you need and independent opinion or help, feel free to contact
+mediat...@xenproject.org. The team behind mediation@ is made up of the
+same community members as those listed in the Conduct Team: see
+[Code of Conduct](code-of-conduct.md). In addition, team members are obligated
+to maintain confidentiality with regard discussions that take place. If you
+have concerns about any of the members of the mediation@ alias, you are
+welcome to contact precisely the team member(s) of your choice. In this case,
+please make certain that you highlight the nature of a request by making sure 
that
+either help or mediation is mentioned in the e-mail subject or body.
+
+## Specific Topics and Best Practice
+
+* [Code Review Guide] (code-review-guide.md):
+  Essential reading for code reviewers and contributors
+* [Communication Best Practice] (communication-practice.md):
+  This guide covers communication guidelines for code reviewers and reviewees. 
It
+  should help you create self-awareness, anticipate, avoid  and help resolve
+  communication issues.
+* [Resolving Disagreement] (resolving-disagreement.md):
+  This guide lays out common situations that can lead to dead-lock and shows 
common
+  patterns on how to avoid and resolve issues.
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 0/6] Code of Conduct + Extra Guides and Best Practices

[Lars Kurth]

From: Lars Kurth 

This series proposes a concrete version of the Xen Project
CoC based on v1.4 of the Contributor Covenant. See [1]

It contains *ALL* the portions I was still going to add.
I spent a bit of time on word-smithing, but I am not a native English speaker
So there is probably time for improvement

The series also reflects the discussion in [2] and some private
discussions on IRC to identify initial members of the Xen
Project’s CoC team.

For convenience of review and in line with other policy documents
I created a git repository at [3]. This series can be found at [5].

[1] https://www.contributor-covenant.org/version/1/4/code-of-conduct.md
[2] https://xen.markmail.org/thread/56ao2gyhpltqmrew 
[3] http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=summary
[4] 
https://www.slideshare.net/xen_com_mgr/xpdds19-keynote-patch-review-for-nonmaintainers-george-dunlap-citrix-systems-uk-ltd
[5] 
http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=shortlog;h=refs/heads/CoC-v2

Changes since v1
* Code of Conduct 
  Only whitespace changes

* Added Communication Guide
  Contains values and a process based on advice and mediation in case of issues
  This is the primary portal for 

* Added Code Review Guide
  Which is based on [4] with some additions for completeness
  It primarily sets expectations and anything communication related is removed

* Added guide on Communication Best Practice
  Takes the communication section from [4] and expands on it with more examples
  and cases. This is probably where we may need some discussion

* Added document on Resolving Disagreement
  A tiny bit of theory to set the scene
  It covers some common cases of disagreements and how we may approach them
  Again, this probably needs some discussion

Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org

Lars Kurth (6):
  Import v1.4 of Contributor Covenant CoC
  Xen Project Code of Conduct
  Add Communication Guide
  Add Code Review Guide
  Add guide on Communication Best Practice
  Added Resolving Disagreement

-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 1/6] Import v1.4 of Contributor Covenant CoC

[Lars Kurth]

From: Lars Kurth 

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 code-of-conduct.md | 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 code-of-conduct.md

diff --git a/code-of-conduct.md b/code-of-conduct.md
new file mode 100644
index 000..81b217c
--- /dev/null
+++ b/code-of-conduct.md
@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, 
body
+size, disability, ethnicity, sex characteristics, gender identity and 
expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies 
when
+an individual is representing the project or its community in public spaces.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event. Representation of
+a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an 
incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], 
version 1.4,
+available at 
https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 2/6] Xen Project Code of Conduct

[Lars Kurth]

From: Lars Kurth 

Specific changes to the baseline:
* Replace list of positive behaviors with link to separate process
* Replace maintainers with project leadership
  (except in our pledge where maintainers is more appropriate)
* Add 'of all sub-projects' to clarify scope of CoC
* Rename Enforcement
* Replace "project team" with "Conduct Team members"
* Add e-mail alias
* Add section on contacting individual Conduct Team members
* Add section on Conduct Team members

Signed-off-by: Lars Kurth 
---
Chagges since v1:
* Addressed newline changes

Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
 code-of-conduct.md | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/code-of-conduct.md b/code-of-conduct.md
index 81b217c..5d6d1d5 100644
--- a/code-of-conduct.md
+++ b/code-of-conduct.md
@@ -1,4 +1,4 @@
-# Contributor Covenant Code of Conduct
+# Xen Project Code of Conduct
 
 ## Our Pledge
 
@@ -11,14 +11,10 @@ appearance, race, religion, or sexual identity and 
orientation.
 
 ## Our Standards
 
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+We believe that a Code of Conduct can help create a harassment-free 
environment,
+but is not sufficient to create a welcoming environment on its own: guidance on
+creating a welcoming environment, how to communicate in an effective and 
friendly
+way, etc. can be found [here](communication-guide.md).
 
 Examples of unacceptable behavior by participants include:
 
@@ -33,11 +29,11 @@ Examples of unacceptable behavior by participants include:
 
 ## Our Responsibilities
 
-Project maintainers are responsible for clarifying the standards of acceptable
+Project leadership team members are responsible for clarifying the standards 
of acceptable
 behavior and are expected to take appropriate and fair corrective action in
 response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or
+Project leadership team members have the right and responsibility to remove, 
edit, or
 reject comments, commits, code, wiki edits, issues, and other contributions
 that are not aligned to this Code of Conduct, or to ban temporarily or
 permanently any contributor for other behaviors that they deem inappropriate,
@@ -45,26 +41,41 @@ threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies within all project spaces, and it also applies 
when
+This Code of Conduct applies within all project spaces of all sub-projects, 
and it also applies when
 an individual is representing the project or its community in public spaces.
 Examples of representing a project or community include using an official
 project e-mail address, posting via an official social media account, or acting
 as an appointed representative at an online or offline event. Representation of
-a project may be further defined and clarified by project maintainers.
+a project may be further defined and clarified by the project leadership.
 
-## Enforcement
+## What to do if you witness or are subject to unacceptable behavior
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
+reported by contacting Conduct Team members at cond...@xenproject.org. All
 complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
+is deemed necessary and appropriate to the circumstances. Conduct Team members 
are
 obligated to maintain confidentiality with regard to the reporter of an 
incident.
 Further details of specific enforcement policies may be posted separately.
 
-Project maintainers who do not follow or enforce the Code of Conduct in good
+If you have concerns about any of the members of the conduct@ alias,
+you are welcome to contact precisely the Conduct Team member(s) of
+your choice.
+
+Project leadership team members who do not follow or enforce the Code of 
Conduct in good
 faith may face temporary or permanent repercussions as determined by other
 members of the project's leadership.
 
+## Conduct Team members
+Conduct Team members are project leadership team members from any
+sub-project. The current list of Conduct Team members is:
+* Lars Kurth 
+* George Dunlap 
+* Ian Jackson 
+
+Conduct Team members are changed by proposing a change to this document,
+posted on all sub-project lists, followed by a formal global vote as outlined
+[here]: https://x

Re: [Xen-devel] [PATCH v2 5/6] Add guide on Communication Best Practice

[Lars Kurth]

On 27/09/2019, 09:59, "Jan Beulich"  wrote:

On 26.09.2019 21:39, Lars Kurth wrote:
> +### Express appreciation
> +As the nature of code review to find bugs and possible issues, it is 
very easy for
> +reviewers to get into a mode of operation where the patch review ends up 
being a list
> +of issues, not mentioning what is right and well done. This can lead to 
the code
> +submitter interpreting your feedback in a negative way.
> +
> +The opening of a code review provides an opportunity to address this and 
also sets the
> +tone for the rest of the code review. Starting **every** review on a 
positive note, helps
> +set the tone for the rest of the review.
> +
> +For an initial patch, you can use phrases such as
> +> Thanks for the patch
> +> Thanks for doing this
> +
> +For further revisions within a review, phrases such as
> +> Thank you for addressing the last set of changes
> +
> +If you believe the code was good, it is good practice to highlight this 
by using phrases
> +such as
> +> Looks good, just a few comments
> +> The changes you have made since the last version look good
> +
> +If you think there were issues too many with the code to use one of the 
phrases,
> +you can still start on a positive note, by for example saying
> +> I think this is a good change
> +> I think this is a good feature proposal
> +
> +It is also entirely fine to highlight specific changes as good. The best 
place to
> +do this, is at top of a patch, as addressing code review comments 
typically requires
> +a contributor to go through the list of things to address and an 
in-lined positive
> +comment is likely to break that workflow.
> +
> +You should also consider, that if you review a patch of an experienced
> +contributor phrases such as *Thanks for the patch* could come across as
> +patronizing, while using *Thanks for doing this* is less likely to be 
interpreted
> +as such.
> +
> +Appreciation should also be expressed by patch authors when asking for 
clarifications
> +to a review or responding to questions. A simple
> +> Thank you for your feedback
> +> Thank you for your reply
> +> Thank you XXX!
> +
> +is normally sufficient.

To all of this I can't resist giving a remark that I've already given
when discussing the matter in person: I'm not sure about English, but
in German the word "Phrase" also has an, at times very, negative
meaning. When I get review feedback starting like suggested above, it
definitely feels to me more like this (the statement was added there
just for it to be there). I realize this may not always (and perhaps
even in a majority of situations) be the case, but that's how it feels
to me nevertheless. As a result I would rather rarely, if ever, start
like this (on the basis of "don't do to others what you dislike
yourself"); a case where I might do so would be when I had asked for
(or offloaded) the putting together of a particular change.

I think your reply proves almost entirely the point of the article. In the
end all of this depends on communication styles (both personal and
cultural). My take to it is that there is a difference between

a) Someone you know: what ultimately will happen is that 
when you engage with someone you know and had done reviews before
you ultimately become more terse and also drop niceties.
Which is OK

b) Someone you don’t know: in that case, we should start from
a reasonable middle ground and put in a bit more effort

Even worse, there have been (also very recent) examples where replies
come back saying just "Thank you" (e.g. for an ack). Such certainly
get sent with good intentions, but people doing so likely overlook
the fact that there's already way too much email to read for many of
us. (The same applies to other netiquette aspects that I keep
mentioning on e.g. summits, but with apparently little to no effect:
People frequently fail to strip unnecessary context when replying,
requiring _every_ reader to scroll through a perhaps long mail just
to find that there's almost nothing of interest. People also seem to
have difficulty understanding the difference between To and Cc.)

That is a good point and I had forgotten about it
Thanks for reminding me

I can add a section on this which looks for balance in the interest
of saving your communication partner's time. Ultimately this is a
also showing a degree of thoughtfulness. 

And we can state in there things like the CC/TO list
And not to thank code reviewers for ACKs or otherwise in a 
stand-alone e-ma

Re: [Xen-devel] [PATCH v2 5/6] Add guide on Communication Best Practice

[Lars Kurth]

On 27/09/2019, 10:14, "Jan Beulich"  wrote:

On 26.09.2019 21:39, Lars Kurth wrote:
> +### Verbose vs. terse
> +Due to the time it takes to review and compose code reviewer, reviewers 
often adopt a
> +terse style. It is not unusual to see review comments such as
> +> typo
> +> s/resions/regions/
> +> coding style
> +> coding style: brackets not needed
> +etc.
> +
> +Terse code review style has its place and can be productive for both the 
reviewer and
> +the author. However, overuse can come across as unfriendly, lacking 
empathy and
> +can thus create a negative impression with the author of a patch. This 
is in particular
> +true, when you do not know the author or the author is a newcomer. Terse
> +communication styles can also be perceived as rude in some cultures.

And another remark here: Not being terse in situations like the ones
enumerated as examples above is a double waste of the reviewer's time:
They shouldn't even need to make such comments, especially not many
times for a single patch (see your mention of "overuse"). I realize
we still have no automated mechanism to check style aspects, but
anybody can easily look over their patches before submitting them.
And for an occasional issue I think a terse reply is quite reasonable
to have.

At the end of the day, none if this is mandatory. The document also
has two audiences
* Authors which get review feedback : for example by just having
this section in there it helps 

I added this section primarily because we do see the occasional
very terse review style and even I think sometimes: wow, that comes
across as harsh. But I also know, that it isn't intentional and that
I have a fairly thick skin. And it is not exclusive to typos and minor issues.

What I was trying to do in this document is to provide
a guide which shows the different patterns from both perspectives.
I hope I succeeded in this, but I believe that you primarily
reviewed the document from the view point of a code reviewer.

Overall I'm seeing the good intentions of this document, yet I'd still
vote at least -1 on it if it came to a vote. Following even just a
fair part of it is a considerable extra amount of time to invest in
reviews, when we already have a severe reviewing bottleneck. If I have
to judge between doing a bad (stylistically according to this doc, not
technically) review or none at all (because of time constraints), I'd
favor the former. Unless of course I'm asked to stop doing so, in
which case I'd expect whoever asks to arrange for the reviews to be
done by someone else in due course.

First of all: this would be our gold standard and as pointed out earlier
So it is intended to provide the tools to do better: for example, from 
my point of view if you followed some of it for example for newcomers
and sparingly when you feel it is right, that would already be a 
win-win. Also, consider that a more positive tone should also have the
effect that there may be less unnecessary discussion. I think this
is particularly true when it comes to the sections on fact-based 
responses vs. some which are unclear. Unfortunately, I don't have data
on this to prove it.

Can I maybe get you to reconsider and re-review the next version from the
view point of an author and maybe make suggestions on how to create more
balance

I'm sorry for (likely) sounding destructive here.

I don't see this your feedback as destructive and do hope that I
can convince you that documenting some of the patterns which
happen on the list are in fact a net-positive

Regards
Lars 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 5/6] Add guide on Communication Best Practice

[Lars Kurth]

On 27/09/2019, 11:17, "Lars Kurth"  wrote:



On 27/09/2019, 10:14, "Jan Beulich"  wrote:

On 26.09.2019 21:39, Lars Kurth wrote:
> +### Verbose vs. terse
> +Due to the time it takes to review and compose code reviewer, 
reviewers often adopt a
> +terse style. It is not unusual to see review comments such as
> +> typo
> +> s/resions/regions/
> +> coding style
> +> coding style: brackets not needed
> +etc.
> +
> +Terse code review style has its place and can be productive for both 
the reviewer and
> +the author. However, overuse can come across as unfriendly, lacking 
empathy and
> +can thus create a negative impression with the author of a patch. 
This is in particular
> +true, when you do not know the author or the author is a newcomer. 
Terse
> +communication styles can also be perceived as rude in some cultures.

And another remark here: Not being terse in situations like the ones
enumerated as examples above is a double waste of the reviewer's time:
They shouldn't even need to make such comments, especially not many
times for a single patch (see your mention of "overuse"). I realize
we still have no automated mechanism to check style aspects, but
anybody can easily look over their patches before submitting them.
And for an occasional issue I think a terse reply is quite reasonable
to have.

At the end of the day, none if this is mandatory. The document also
has two audiences
* Authors which get review feedback : for example by just having
this section in there it helps 

This was meant to read: it helps set expectations and promotes 
understanding for some of the patterns used

I added this section primarily because we do see the occasional
very terse review style and even I think sometimes: wow, that comes
across as harsh. But I also know, that it isn't intentional and that
I have a fairly thick skin. And it is not exclusive to typos and minor 
issues.

 Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Vote] XCP-ng subproject proposal

[Lars Kurth]

> On 9 Sep 2019, at 15:44, Lars Kurth  wrote:
> 
> Hello everyone,
> 
> Olivier had posted an RFC for this proposal on xen-devel@- see 
> https://xen.markmail.org/thread/ermnrb3ps3okvnjr 
> <https://xen.markmail.org/thread/ermnrb3ps3okvnjr> 
> 
> The proposal also has been discussed by the Advisory Board and was approved
> 
> However, for the proposal to fully pass the proposal must be run by past all 
> mature subproject, which are Hypervisors, Windows PV Drivers and XAPI (see 
> https://xenproject.org/developers/governance/#project-decisions 
> <https://xenproject.org/developers/governance/#project-decisions>). People 
> listed under Project team visible on the right columns of following pages can 
> vote
> * https://xenproject.org/developers/teams/xen-hypervisor/ 
> <https://xenproject.org/developers/teams/xen-hypervisor/> - already voted: 
> Jan, Ian, Wei, George
> * https://xenproject.org/developers/teams/windows-pv-drivers/ 
> <https://xenproject.org/developers/teams/windows-pv-drivers/>
> * https://xenproject.org/developers/teams/xen-api/ 
> <https://xenproject.org/developers/teams/xen-api/>
> 
> The RFC proposal has passed the Hypervisor team with 4/8 votes (see 
> https://xen.markmail.org/thread/ermnrb3ps3okvnjr 
> <https://xen.markmail.org/thread/ermnrb3ps3okvnjr>), but more support would 
> be appreciated
> 
> The proposal is attached below. Please vote before next Tuesday
> 
> Best Regards
> Lars

Hi all.
so no more votes which means the proposal has passed
Lard

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ANNOUNCE] Call for agenda items for Oct, 10th Community Call @ 15:00 UTC - One week later than normal

[Lars Kurth]

Hi all,

the proposed agenda is in 
https://cryptpad.fr/pad/#/2/pad/edit/4FGEw81flPUiivkjkuvQJ-CK/embed/present/and 
you can edit to add items
Alternatively, you can reply to this mail directly

Agenda items appreciated a few days before the call: please put your name 
besides items if you edit the document

Best Regards
Lars
P.S.: If you want to be added or removed from the CC list please reply privately

== Dial-in Information ==
## Meeting time
15:00 - 16:00 UTC
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=10&day=10&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=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
Ukraine (Toll Free): 0 800 50 1733
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129
Spain: +34 932 75 2004

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
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
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

Re: [Xen-devel] [VOTE] tagging for operational messages sent to xen-devel@ (was Re: Xen 4.13 Development Update)

[Lars Kurth]

Hi all,

I almost dropped this: apologies. With the votes in, we have a clear winner for 
[ANNOUNCE] over the other options

ANNOUNCE1   2   2
OPERATIONS  -1  -1  1
PROCESS 0   0   -2

Lars

On 26/04/2019, 03:50, "Jan Beulich"  wrote:

>>> On 25.04.19 at 18:36,  wrote:
> Alright,
> 
> there was a lengthy discussion on this topic on IRC - log attached. The 
> consensus appears to be to use Canonical messages with a CAPITALISED tag. 
> E.g. "[TAG] Xen 4.13 Development Update".
> 
> The options which seemed to have least objections are
> 1: [ANNOUNCE]

+1

If mails to xen-announce really get reflected to xen-devel (I didn't
know this, and hence would have pointlessly sent stable release
announcements to both lists), then preferably with the tag
getting added in the process of reflecting.

> 2: [OPERATIONS] 

-1

> 3: [PROCESS]

0

Jan




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [VOTE] tagging for operational messages sent to xen-devel@ (was Re: Xen 4.13 Development Update)

[Lars Kurth]

Rich,
as nobody replied to the mail, I am inclined to dismiss the proposal of ANN for 
now
Lars

> On 25 Apr 2019, at 16:59, Rich Persaud  wrote:
> 
>> On Apr 25, 2019, at 12:36, Lars Kurth  wrote:
>> 
>> Alright,
>> 
>> there was a lengthy discussion on this topic on IRC - log attached. The 
>> consensus appears to be to use Canonical messages with a CAPITALISED tag. 
>> E.g. "[TAG] Xen 4.13 Development Update".
>> 
>> The options which seemed to have least objections are
>> 1: [ANNOUNCE]
>> 2: [OPERATIONS] 
>> 3: [PROCESS]
>> 
>> And that we should use these for other messages/announcements related to the 
>> operation of Xen Project Development.
> 
> On mobile devices, shorter subjects are better.  A [xen-devel] email already 
> has one 11-character tag. Since tags are in CAPITALS, abbreviated tags = less 
> SHOuting.
> 
>> [Diziet] Only because we copy everything from -announce to -devel.
> 
> Some mailing lists use [ANN] for announcements.  Email mirrored to xen-devel 
> from -announce could prefix the [ANN] tag, which would not be used for 
> non-mirrored email, since all announcements would be directed to -announce.
> 
>> [gwd] But in my mind, things like RM updates (which happen pretty regularly) 
>> and say, Developer Summit announcements, are different things.
> 
> The messages which prompted this discussion were related to release 
> management.  These were called RM in the IRC discussion, which suggests [RM] 
> as a possible tag.  It's quick to type and non-distracting to read.  This 
> would not preclude other tags for non [RM] messages.
> 
> Rich
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] No community call this week, but next week

[Lars Kurth]

Hi all,
I forgot to update my calendar to reflect for the new community call time and 
thus forgot to ask for agenda items. Sincere apologies. So I propose we have 
the meeting next week. Will send out agenda requests tomorrow
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [VOTE] tagging for operational messages sent to xen-devel@ (was Re: Xen 4.13 Development Update)

[Lars Kurth]

On 01/05/2019, 12:56, "Rich Persaud"  wrote:

> On May 1, 2019, at 14:37, Lars Kurth  wrote:
> 
> Rich,
> as nobody replied to the mail, I am inclined to dismiss the proposal of 
ANN for now
> Lars

What do you think about the suggestion to apply a tag ("ANNOUNCE"?) for 
emails that are mirrored to xen-devel from the -announce mailing list?  Jan 
commented on that suggestion in a separate thread.

I think that's fine, although we may have to change how the announce list 
works, otherwise on that list we get "[xen-announce] [ANNOUNCE] ..." if 
messages are cross posted, which would be odd and will surely annoy some people
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] sched/credit: avoid priority boost for capped domains when unpark

[Lars Kurth]

> On 3 May 2019, at 10:48, Dario Faggioli  wrote:
> 
> On Fri, 2019-05-03 at 15:38 +, Eslam Elnikety wrote:
>> When unpausing a capped domain, the scheduler currently clears the
>> CSCHED_FLAG_VCPU_PARKED flag before vcpu_wake(). This, in turn,
>> causes the
>> vcpu_wake to set CSCHED_PRI_TS_BOOST, resulting in an unfair credit
>> boost. The
>> comment around the changed lines already states that clearing the
>> flag should
>> happen AFTER the unpause. This bug was introduced in commit
>> be650750945
>> "credit1: Use atomic bit operations for the flags structure".
>> 
>> Original patch author credit: Xi Xiong.
>> 
> Mmm... I'm not an expert of these things, but doesn't this means we
> need a "Signed-off-by: Xi Xiong " then? Cc-ing Lars...

As far as I can tell from a quick search on xen-devel@ Xi Xiong is or 
was an Amazon employee so a signed-off-by is not strictly necessary
but you may want to say something like.

Original patch author credit: Xi Xiong of Amazon

Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,

Please propose topics by either editing the running agenda document at 
https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
 or by replying to the mail. Ideally by Wednesday!

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&month=5&day=9&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=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

Re: [Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

[Lars Kurth]

> On 6 May 2019, at 09:11, Woods, Brian  wrote:
> 
> On Mon, May 06, 2019 at 07:51:17AM -0600, Lars Kurth wrote:
>> [CAUTION: External Email]
>> 
>> Hi all,
>> 
>> Please propose topics by either editing the running agenda document at 
>> https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
>>  or by replying to the mail. Ideally by Wednesday!
>> 
>> Best Regards
>> Lars
>> 
> 
> I'd like to add the AMD mwait V2 patch set to the list of topics.  I'd
> like to come to some sort of conclusion about that set.
> 

I would like to add an item related to "[Xen-devel] Criteria / validation 
proposal: drop Xen" which raises some questions about testing. More details to 
follow

Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

[Lars Kurth]

I added these to the agenda 
https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
 
<https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#>
Feel free to add to it
Lars

> On 6 May 2019, at 09:23, Lars Kurth  wrote:
> 
> 
> 
>> On 6 May 2019, at 09:11, Woods, Brian > <mailto:brian.wo...@amd.com>> wrote:
>> 
>> On Mon, May 06, 2019 at 07:51:17AM -0600, Lars Kurth wrote:
>>> [CAUTION: External Email]
>>> 
>>> Hi all,
>>> 
>>> Please propose topics by either editing the running agenda document at 
>>> https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
>>>  
>>> <https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#>
>>>  or by replying to the mail. Ideally by Wednesday!
>>> 
>>> Best Regards
>>> Lars
>>> 
>> 
>> I'd like to add the AMD mwait V2 patch set to the list of topics.  I'd
>> like to come to some sort of conclusion about that set.
>> 
> 
> I would like to add an item related to "[Xen-devel] Criteria / validation 
> proposal: drop Xen" which raises some questions about testing. More details 
> to follow
> 
> Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

Hi all,

following a discussion with committers about Guest testing in OSSTEST, it 
surfaced that we have not updated what distros we test in OSSTEST for a very 
long time. All agreed that we should regularly review what we test against: 
maybe at the beginning of a release cycle

In any case, currently we test against

x86 HVM guests:
  debian-9.4.0-{i386,amd64}-CD-1.iso
  rhel-server-6.1-i386-dvd.iso
  win10v1703-x86.iso
  win7-x64.iso
  ws16-x64.iso
  FreeBSD-10.1-CUSTOM-{i386,amd64}-20150525.raw.xz
  Debian HVM {i386,amd64} via debian-installer netinst [1]

x86 PV guests:
  Debian PV {i386,amd64} via debian-installer netinst [1]

ARM guests:
  Debian PV via debian-installer netinst [1]

[1] whatever Debian release osstest itself mostly runs

So I am opening the floor to suggestions.

With regards to Windows testing we have some restrictions. We have tried 
several times to buy additional test licenses, but this never went anywhere 
(some of the VM licenses are not available for our environment, unless you bulk 
buy, which is very expensive). The only approach that would allow us to test 
against different windows versions would be to require everyone who may touch 
OSSTEST which is not doable.

I can bring this up with the MS open source office, if there are strong 
feelings about this and try again

Lars

  
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

> On 10 May 2019, at 01:48, Jan Beulich  wrote:
>> 
>> With regards to Windows testing we have some restrictions. We have tried 
>> several times to buy additional test licenses, but this never went anywhere 
>> (some of the VM licenses are not available for our environment, unless you 
>> bulk buy, which is very expensive). The only approach that would allow us to 
>> test against different windows versions would be to require everyone who may 
>> touch OSSTEST which is not doable.
>> 
>> I can bring this up with the MS open source office, if there are strong 
>> feelings about this and try again
> 
> If there's at least a (not overly) small chance of succeeding, I think this
> may be worth it, unless Rich's suggestion already helps.
> 

I will try again. Let's work on the basis that this is possible and see where 
it goes
Lars___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] RFC: File format to allow us to track imported files

[Lars Kurth]

Hi all,

following the recent discussion, we had on IRC and the action I had in the March
community call, I wanted to make a proposal related to the file format to track
files. I am not yet submitting a fully formed patch as there may be differing
opinions about the file format and name of the file.

I propose TRACKINGIMPORTS or for better readability TRACKING.IMPORTS in the
xen.git root as file name, but don’t have a strong opinion.

Ian originally proposed to add all information related to a mapping into
one single line. That however leads to VERY long lines. So, I decided to break
repository definitions into separate statements and allow referring to repos by
a shorthand.

That also has the advantage that should source repository locations ever change,
only a single line needs modification.

Let me know what you think.

Cheers
Lars

# This file contains information about source files that have been
# copied from other sources and need to be tracked
#
# The file may contain lines starting with ...
# 
# version: of file format
# repo: repository definition
# manual|auto: a mapping to track files
#
# Repository Definitions are of the following format
# --
# repo name-of-source-repo git|svn https-url-of-source-repo
#
# Mappings to track files are of the following format
# ---
# manual|auto xen-file name-of-source-repo source-file commit-id
#
# auto: we can automatically update the file using a script
# manual: a committer needs to make a decision as to whether a
#   change is applied or ignored and update the last commit id
#   accordingly
# name-of-source-repo: must be defined by *repo*
# commit id: last commit id of source file that was deemed to be ok
#   and either imported into the tree or rejected
#
version 1

# Example of a repository definitions
repo linux-master git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

# Example of a mapping
manual xen/drivers/passthrough/arm/smmu.c linux-master 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ANNOUNCE] Xen Developer and Design Summit Program for 2019 is live

[Lars Kurth]

Dear Community Members,

we are excited to unveil the Xen Project Developer and Design Summit program 
and speaker schedule [1]. The ​Xen Project ​Developer ​and ​Design ​Summit 
​brings ​together ​the ​Xen ​Project’s ​community ​of ​developers ​and ​power 
​users ​for ​their ​annual ​conference. ​The ​conference ​is ​about ​sharing 
​ideas ​and ​the ​latest ​developments, ​sharing ​experience, ​planning, 
​collaboration ​and ​above ​all ​to ​have ​fun ​and ​to ​meet ​the ​community 
​that ​defines ​the ​Xen ​Project.
This year’s Summit is taking place in Chicago from July 9th to 11th [2]. 

In addition to presentations, the Xen Project will be running design sessions. 
These are problem-solving sessions with tangible outputs. Community members can 
submit sessions until July 10th [3]. 

To submit a design session, go to [3]
For a full list of submitted design sessions, go to [4]

Check out the event page for all details and we look forward to seeing you in 
July!

Best Regards
Lars

[1] https://events.linuxfoundation.org/events/xensummit-2019/program/schedule/
[2] https://events.linuxfoundation.org/events/xensummit-2019/
[3] https://design-sessions.xenproject.org/
[4] https://design-sessions.xenproject.org/list/discussion
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] docs/xl: Clarify documentation for mem-max and mem-set

[Lars Kurth]

On 13/05/2019, 08:28, "Wei Liu"  wrote:

On Mon, May 13, 2019 at 02:59:30PM +0100, Wei Liu wrote:
> On Wed, May 01, 2019 at 03:59:41PM +0100, George Dunlap wrote:
> > On 4/8/19 12:09 PM, George Dunlap wrote:
> > > mem-set is the primary command that users will need to use and
> > > understand.  Move it first, and clarify the wording; also specify that
> > > you can't set the target higher than maxmem from the domain config.
> > > 
> > > mem-max is actually a pretty useless command at the moment.  Clarify
> > > that users are not expected to use it; and document all of its quirky
> > > behavior.
> > > 
> > > Signed-off-by: George Dunlap 
> > 
> > Wei / Ian: Ping?
> > 
> > Juergen replied to my "review note" comment, not to anything actionable
> > in the patch (or commit message) itself.
> 
> Acked-by: Wei Liu 
> 
> (I already said this looked okay to me in v1)

I believe Lars' Rb from v1 still stands.

Yes
Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

Hi all,

I am going to step in here with my hat as Xen Project community
manager. We had a discussion about this issue as part of last week's
community call. I CC'ed a number of stake-holders, which probably
should have been on the thread such as ITL (which builds QubesOS
on top of Fedora) and Michael A Young (the Xen package manager).

First of all apologies that this issue has lingered so long. Key
members of the community were not aware of the issues raised in
this thread, otherwise we would have acted earlier. With this in
mind, please in future raise issues with me, on xen-devel@,
committers@ or the Xen-Fedora package manager. The Xen Community
would like to see Fedora running as guest: in fact it would be
somewhat odd if there was a Xen-Dom0 package and guest support
didn't work. And there are some downstreams such as QubesOS,
which depend on this support.

> On 6 Jul 2017, at 13:45, Adam Williamson  wrote:
> 
> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
>>> Hi, folks! A while ago, Xen virtualization functionality was added to
>>> the criteria and the validation test case set, on the understanding
>>> that Oracle would provide testing for it (and help fix bugs as they
>>> arose).
>>> 
>>> For the last couple of releases we really have not had any such testing
>> 
>> We had been doing the testing, it just that we (or rather me and
>> Dariof) seem to get a wind of this at the last minute. Not sure exactly
>> how to fix that thought.
> 
> Well, I mean, every few *days* a compose gets nominated for validation
> testing, and a mail is sent to test-announce. Just check your test-
> announce archives for mails with "nominated for testing" in their
> subject lines, and you'll see dozens. Is this not sufficient
> notification?

We discussed this at the community call and came to the conclusion that
we can run regular tests of Fedora RC's as part of our OSSTEST
infrastructure. Ian Jackson volunteered to implement this, but there
are some questions on
a) The installer (which we can handle ourselves)
b) When we would trigger a test - aka is there some trigger other than the
c) How would results best be reported back to Fedora

Apologies, I am not very familiar with how the Fedora Test group works.
Is there some documentation which would help integrate what you to with
the test system of another open source project?

>>> from Oracle. On that basis, I'm proposing we remove this Final
>>> criterion:
>> 
>> s/Oracle/Xen Project/ I believe?
> 
> Perhaps, it's just that it always seemed to be you doing the testing,
> so they got a bit conflated :)

Can we come to some arrangement, by which such issues get communicated
to the Xen Project earlier? Aka me, xen-devel@ or committers@

>>> "The release must boot successfully as Xen DomU with releases providing
>>> a functional, supported Xen Dom0 and widely used cloud providers
>>> utilizing Xen."
>>> 
>>> and change the 'milestone' for the test case -
>>> https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
>>> from Final to Optional.
>>> 
>>> Thoughts? Comments? Thanks!
>> 
>> I would prefer for it to remain as it is.
> 
> This is only practical if it's going to be tested, and tested regularly
> - not *only* on the final release candidate, right before we sign off
> on the release. It needs to be tested regularly throughout the release
> cycle, on the composes that are "nominated for testing".

Would the proposal above work for you? I think it satisfies what you are
looking for. We would also have someone who monitors these test results
pro-actively.

Then, there are the specific grub issues that need resolving
[A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002
 (and a recently filed duplicate @
  https://bugzilla.redhat.com/show_bug.cgi?id=1691559) caused by
  [A2])
[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1264103

The first makes it harder to boot Fedora _dom0_ (but workarounds exist).
While it is unpleasant, it doesn't break the release criterion, but
probably has deterred people from testing. The second one [B1] is about
Fedora _domU_, which breaks the release criterion.

Marek and Michael had a discussion about these and there was also
a summary from Daniel.

== On [A1]/[A2] ==
Lack of GRUB2 multiboot2/module2 commands in Fedora/RH which does not
allow you load Xen as dom0 on EFI platforms with or without secure
boot. Here are some relevant snippets from the discussions:

"In general both modules were dropped due to CVE-2015-5281 (grub2:
modules built in on EFI builds that allow loading arbitrary code,
circumventing secure boot) [A3][A4]. Of course this makes sense
because we do not want to break UEFI secure boot. But this means
that you cannot boot Xen dom0 on UEFI platforms. The Multiboot2
protocol support is required to do that. Potentially you can
use xen.efi directly but AFA

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

Apologies,
I mixed up some references
Lars

> On 13 May 2019, at 16:29, Lars Kurth  wrote:
> 
> Hi all,
> 
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders, which probably
> should have been on the thread such as ITL (which builds QubesOS
> on top of Fedora) and Michael A Young (the Xen package manager).
> 
> First of all apologies that this issue has lingered so long. Key
> members of the community were not aware of the issues raised in
> this thread, otherwise we would have acted earlier. With this in
> mind, please in future raise issues with me, on xen-devel@,
> committers@ or the Xen-Fedora package manager. The Xen Community
> would like to see Fedora running as guest: in fact it would be
> somewhat odd if there was a Xen-Dom0 package and guest support
> didn't work. And there are some downstreams such as QubesOS,
> which depend on this support.
> 
>> On 6 Jul 2017, at 13:45, Adam Williamson  wrote:
>> 
>> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
>>>> Hi, folks! A while ago, Xen virtualization functionality was added to
>>>> the criteria and the validation test case set, on the understanding
>>>> that Oracle would provide testing for it (and help fix bugs as they
>>>> arose).
>>>> 
>>>> For the last couple of releases we really have not had any such testing
>>> 
>>> We had been doing the testing, it just that we (or rather me and
>>> Dariof) seem to get a wind of this at the last minute. Not sure exactly
>>> how to fix that thought.
>> 
>> Well, I mean, every few *days* a compose gets nominated for validation
>> testing, and a mail is sent to test-announce. Just check your test-
>> announce archives for mails with "nominated for testing" in their
>> subject lines, and you'll see dozens. Is this not sufficient
>> notification?
> 
> We discussed this at the community call and came to the conclusion that
> we can run regular tests of Fedora RC's as part of our OSSTEST
> infrastructure. Ian Jackson volunteered to implement this, but there
> are some questions on
> a) The installer (which we can handle ourselves)
> b) When we would trigger a test - aka is there some trigger other than the
> c) How would results best be reported back to Fedora
> 
> Apologies, I am not very familiar with how the Fedora Test group works.
> Is there some documentation which would help integrate what you to with
> the test system of another open source project?
> 
>>>> from Oracle. On that basis, I'm proposing we remove this Final
>>>> criterion:
>>> 
>>> s/Oracle/Xen Project/ I believe?
>> 
>> Perhaps, it's just that it always seemed to be you doing the testing,
>> so they got a bit conflated :)
> 
> Can we come to some arrangement, by which such issues get communicated
> to the Xen Project earlier? Aka me, xen-devel@ or committers@
> 
>>>> "The release must boot successfully as Xen DomU with releases providing
>>>> a functional, supported Xen Dom0 and widely used cloud providers
>>>> utilizing Xen."
>>>> 
>>>> and change the 'milestone' for the test case -
>>>> https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
>>>> from Final to Optional.
>>>> 
>>>> Thoughts? Comments? Thanks!
>>> 
>>> I would prefer for it to remain as it is.
>> 
>> This is only practical if it's going to be tested, and tested regularly
>> - not *only* on the final release candidate, right before we sign off
>> on the release. It needs to be tested regularly throughout the release
>> cycle, on the composes that are "nominated for testing".
> 
> Would the proposal above work for you? I think it satisfies what you are
> looking for. We would also have someone who monitors these test results
> pro-actively.
> 
> Then, there are the specific grub issues that need resolving
> [A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1486002>
> (and a recently filed duplicate @
>  https://bugzilla.redhat.com/show_bug.cgi?id=1691559 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1691559>) caused by
>  [A2])
> [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1703700>
> 

[Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

Following the recent discussion, we had on IRC and the action I had in 
the March community call, this file provides a file format that 
enables writing an automated test to check whether files are out of sync. 

Unlike in the IRC discussion, which suggested a single line for all
information, I broke out the repository into a separate statement for
- Better readability (aka shorter lines)
- Better maintainability if a repo URL changes

The list of files that need to be included are

Once the file format is agree, I will write a test or script.

I also need some more correct test data, aka entries in the file from
committers looking after the following files
[Jan]
xen/arch/x86/cpu/mwait-idle.c 
[Stefano, Julien - this has to be finalized]
xen/drivers/passthrough/arm/smmu.c
xen/arch/arm/vgic/*
xen/include/asm-arm/div64.h
xen/drivers/char/meson-uart.c
xen/arch/arm/arm32/lib/*
xen/arch/arm/arm64/lib/*
xen/arch/arm/arm64/cache.S
xen/arch/arm/arm64/bpi.S
xen/include/asm-arm/system.h
xen/arch/arm/arm64/insn.c
[Others?]
xen/common/rbtree.c

Note that in some cases Linux has diverged and some Linux files have 
disappeared. 
Julien also raised the point, that in some cases only a subset of code from 
Linux Xen files was applied or that only some functions get moved across to Xen.

I believe that is entirely OK. The workflow would be in most cases that:
- We use a Linux (source) commit as a benchmark and record the commit ID
- If there is a change in Linux the test will fail
- The committer looks at the diff and either
  - Decides to ignore it and bumps the commit ID in this file
  - Decides the change is needed, integrates it into Xen and then 
bumps the commit ID in this file

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org
---
 TRACKING.IMPORTS | 40 
 1 file changed, 40 insertions(+)
 create mode 100644 TRACKING.IMPORTS

diff --git a/TRACKING.IMPORTS b/TRACKING.IMPORTS
new file mode 100644
index 00..39829e078c
--- /dev/null
+++ b/TRACKING.IMPORTS
@@ -0,0 +1,40 @@
+# This file contains information about source files that have been
+# copied from other sources and need to be tracked
+#
+# The file may contain lines starting with ...
+# 
+# version: of file format
+# repo: repository definition
+# auto|manual: a mapping to track files
+#
+# Repository Definitions are of the following format
+# --
+# repo name-of-source-repo git|svn https-url-of-source-repo
+#
+# For example:
+#   repo linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+#
+# Mappings to track files are of the following format
+# ---
+# manual|auto xen-file name-of-original-repo original-file commit-id
+#
+# auto:
+#   The xen-file needs to track the the original-file exactly
+#   In other words, we can automatically update the file using a script
+#
+# manual:
+#   A developer needs to make a decision whether a
+#   specific change is applied or ignored and update the last commit id
+#   accordingly
+#
+# name-of-original-repo:
+#   A reference to a source repository defined by *repo* keyword
+#
+# commit id:
+#   Last commit id of source file that was deemed to be ok
+#   and either imported into the tree or rejected
+#
+# For example:
+#   manual xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
+
+version 1
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 16/05/2019, 04:47, "Jan Beulich"  wrote:

>>> On 16.05.19 at 00:18,  wrote:
> +# Mappings to track files are of the following format
> +# ---
> +# manual|auto xen-file name-of-original-repo original-file commit-id
> +#
> +# auto:
> +#   The xen-file needs to track the the original-file exactly
> +#   In other words, we can automatically update the file using a script

Do we have _any_ example of this? I can't even imagine one, due
to e.g. our includes all starting with xen/ whereas Linux'es (just to
take as example) all start with linux/. Perhaps "auto" needs to
include sed expressions that need to be applied before actually
applying the original change to our tree?

I am not sure I fully understand your concern. 
This was intended for the case where say we would exactly track xen/.../foo.bar 
with linux/.../foo.bar
In other words, auto only applies to the content of a file: the filename isn't 
relevant, because all the information that would be needed to do this is in the 
file.

But if there is no need for it, we can drop it. And if needed, we can add in 
future.
@Julien, @Stefano, @Jan: are any of the files you listed fall into the "should 
be tracked exactly" category?

> +# manual:
> +#   A developer needs to make a decision whether a
> +#   specific change is applied or ignored and update the last commit id
> +#   accordingly
> +#
> +# name-of-original-repo:
> +#   A reference to a source repository defined by *repo* keyword
> +#
> +# commit id:
> +#   Last commit id of source file that was deemed to be ok
> +#   and either imported into the tree or rejected
> +#
> +# For example:
> +#   manual xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
> +
> +version 1

Perhaps it wouldn't hurt to include the colons in the actual entries as
well? 

I am not sure what you mean, which colons? Are you saying, the format should be
version: 1
repo: ...

I think the confusion comes because I used colons after statements in the 
comments. 
I think that "version: 1" is slightly more human-readable, so I would be OK 
with that

I also don't think examples are needed once we get the first
real entries. Hence I'd move them to the commit message or a
post-commit message remark.

Agreed.

Lars





___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 17/05/2019, 01:34, "Jan Beulich"  wrote:

>>> On 16.05.19 at 17:54,  wrote:

> 
> On 16/05/2019, 04:47, "Jan Beulich"  wrote:
> 
> >>> On 16.05.19 at 00:18,  wrote:
> > +# Mappings to track files are of the following format
> > +# ---
> > +# manual|auto xen-file name-of-original-repo original-file 
commit-id
> > +#
> > +# auto:
> > +#   The xen-file needs to track the the original-file exactly
> > +#   In other words, we can automatically update the file using a 
script
> 
> Do we have _any_ example of this? I can't even imagine one, due
> to e.g. our includes all starting with xen/ whereas Linux'es (just to
> take as example) all start with linux/. Perhaps "auto" needs to
> include sed expressions that need to be applied before actually
> applying the original change to our tree?
> 
> I am not sure I fully understand your concern. 
> This was intended for the case where say we would exactly track 
> xen/.../foo.bar with linux/.../foo.bar
> In other words, auto only applies to the content of a file: the filename 
> isn't relevant, because all the information that would be needed to do 
this 
> is in the file.

When talking about file names in my reply, I referred to C language
#include directives inside the file in question, as a (pretty important)
example. There was no talk about the cloned/copied file's name itself.
Hence the suggestion to accompany auto: with a set of sed
expressions, which could then e.g. transform #include 
into #include .

That makes perfect sense now. In that case, I tend to agree that "auto" is 
probably not needed. Would be quite happy to drop it.

> @Julien, @Stefano, @Jan: are any of the files you listed fall into the 
> "should be tracked exactly" category?

As I've said before - I can't even imagine such a file to exist.

> > +# manual:
> > +#   A developer needs to make a decision whether a
> > +#   specific change is applied or ignored and update the last 
commit id
> > +#   accordingly
> > +#
> > +# name-of-original-repo:
> > +#   A reference to a source repository defined by *repo* keyword
> > +#
> > +# commit id:
> > +#   Last commit id of source file that was deemed to be ok
> > +#   and either imported into the tree or rejected
> > +#
> > +# For example:
> > +#   manual xen/drivers/passthrough/arm/smmu.c linux-torvalds 
> linux/drivers/iommu/arm-smmu.c b77cf11f094136
> > +
> > +version 1
> 
> Perhaps it wouldn't hurt to include the colons in the actual entries 
as
> well? 
> 
> I am not sure what you mean, which colons? Are you saying, the format 
should be
> version: 1
> repo: ...

Yes. This would make it even more prominent that these are tags of
some sort. But this was only a thought of mine, it's in no way meant
to be a requirement I have.

> I think the confusion comes because I used colons after statements in the 
> comments. 

Right, that's how I got there.

> I think that "version: 1" is slightly more human-readable, so I would be 
OK 
> with that

A well defined non-blank separator also allows machine processing
to notice more easily if there's a malformed line. Plus (if need be)
it would permit tags with blanks in their names.

I can do that. No problem.

Any other comments from anyone, before sending version 2?

Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 20/05/2019, 10:37, "Ian Jackson"  wrote:

This is going in the right direction IMO.
    
Lars Kurth writes ("Re: [PATCH] Add TRACKING.IMPORTS to xen.git to more 
easily manage imported files that need to be kept in sync with an upstream"):
> That makes perfect sense now. In that case, I tend to agree that "auto" 
is probably not needed. Would be quite happy to drop it.

It will considerably complicate things to add a way to define
seddery.  Let us leave that to a future extension.

That suggests that `manual' should become `file:'.

As for delimiters

> On 17/05/2019, 01:34, "Jan Beulich"  wrote:
> > I am not sure what you mean, which colons? Are you saying, the 
format should be
> > version: 1
> > repo: ...
> 
> Yes. This would make it even more prominent that these are tags of
> some sort. But this was only a thought of mine, it's in no way meant
> to be a requirement I have.

It will make writing a parser easier if each entry is a single line
with the fields in a defined order and if we can say that a `repo:'
must precede every `file:' that mentions it.

That sounds perfectly sensible
Version 2 on its way, sometimes next week

Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

@Adam and Fedora Testing & QA:
any views on my proposal?
Regards
Lars

> On 13 May 2019, at 16:29, Lars Kurth  wrote:
> 
> Hi all,
> 
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders, which probably
> should have been on the thread such as ITL (which builds QubesOS
> on top of Fedora) and Michael A Young (the Xen package manager).
> 
> First of all apologies that this issue has lingered so long. Key
> members of the community were not aware of the issues raised in
> this thread, otherwise we would have acted earlier. With this in
> mind, please in future raise issues with me, on xen-devel@,
> committers@ or the Xen-Fedora package manager. The Xen Community
> would like to see Fedora running as guest: in fact it would be
> somewhat odd if there was a Xen-Dom0 package and guest support
> didn't work. And there are some downstreams such as QubesOS,
> which depend on this support.
> 
>> On 6 Jul 2017, at 13:45, Adam Williamson  wrote:
>> 
>> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
>>>> Hi, folks! A while ago, Xen virtualization functionality was added to
>>>> the criteria and the validation test case set, on the understanding
>>>> that Oracle would provide testing for it (and help fix bugs as they
>>>> arose).
>>>> 
>>>> For the last couple of releases we really have not had any such testing
>>> 
>>> We had been doing the testing, it just that we (or rather me and
>>> Dariof) seem to get a wind of this at the last minute. Not sure exactly
>>> how to fix that thought.
>> 
>> Well, I mean, every few *days* a compose gets nominated for validation
>> testing, and a mail is sent to test-announce. Just check your test-
>> announce archives for mails with "nominated for testing" in their
>> subject lines, and you'll see dozens. Is this not sufficient
>> notification?
> 
> We discussed this at the community call and came to the conclusion that
> we can run regular tests of Fedora RC's as part of our OSSTEST
> infrastructure. Ian Jackson volunteered to implement this, but there
> are some questions on
> a) The installer (which we can handle ourselves)
> b) When we would trigger a test - aka is there some trigger other than the
> c) How would results best be reported back to Fedora
> 
> Apologies, I am not very familiar with how the Fedora Test group works.
> Is there some documentation which would help integrate what you to with
> the test system of another open source project?
> 
>>>> from Oracle. On that basis, I'm proposing we remove this Final
>>>> criterion:
>>> 
>>> s/Oracle/Xen Project/ I believe?
>> 
>> Perhaps, it's just that it always seemed to be you doing the testing,
>> so they got a bit conflated :)
> 
> Can we come to some arrangement, by which such issues get communicated
> to the Xen Project earlier? Aka me, xen-devel@ or committers@
> 
>>>> "The release must boot successfully as Xen DomU with releases providing
>>>> a functional, supported Xen Dom0 and widely used cloud providers
>>>> utilizing Xen."
>>>> 
>>>> and change the 'milestone' for the test case -
>>>> https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
>>>> from Final to Optional.
>>>> 
>>>> Thoughts? Comments? Thanks!
>>> 
>>> I would prefer for it to remain as it is.
>> 
>> This is only practical if it's going to be tested, and tested regularly
>> - not *only* on the final release candidate, right before we sign off
>> on the release. It needs to be tested regularly throughout the release
>> cycle, on the composes that are "nominated for testing".
> 
> Would the proposal above work for you? I think it satisfies what you are
> looking for. We would also have someone who monitors these test results
> pro-actively.
> 
> Then, there are the specific grub issues that need resolving
> [A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1486002>
> (and a recently filed duplicate @
>  https://bugzilla.redhat.com/show_bug.cgi?id=1691559 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1691559>) caused by
>  [A2])
> [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103 
> <https://bugzilla.redhat.com/s

[Xen-devel] [PATCH v2] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

Following the recent discussion, we had on IRC and the action I had in 
the March community call, this file provides a file format that 
enables writing an automated test to check whether files are out of sync. 

Once the file format is agree, I will write a test or script.

I also need some more correct test data, aka entries in the file from
committers looking after the following files
[Jan]
xen/arch/x86/cpu/mwait-idle.c 
[Stefano, Julien - this has to be finalized]
xen/drivers/passthrough/arm/smmu.c
xen/arch/arm/vgic/*
xen/include/asm-arm/div64.h
xen/drivers/char/meson-uart.c
xen/arch/arm/arm32/lib/*
xen/arch/arm/arm64/lib/*
xen/arch/arm/arm64/cache.S
xen/arch/arm/arm64/bpi.S
xen/include/asm-arm/system.h
xen/arch/arm/arm64/insn.c
[Others?]
xen/common/rbtree.c

Note that in some cases Linux has diverged and some Linux files have 
disappeared. 
Julien also raised the point, that in some cases only a subset of code from 
Linux Xen files was applied or that only some functions get moved across to Xen.

I believe that is entirely OK. The workflow would be in most cases that:
- We use a Linux (source) commit as a benchmark and record the commit ID
- If there is a change in Linux the test will fail
- The committer looks at the diff and either
  - Decides to ignore it and bumps the commit ID in this file
  - Decides the change is needed, integrates it into Xen and then 
bumps the commit ID in this file

Changes since v1
* Require a colon after repo:, file:, ... keywords
* Replace manual:|auto: with file: as there auto: use-case was invalid
* Added more verbose description of format

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org

---
 TRACKING.FILES | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 TRACKING.FILES

diff --git a/TRACKING.FILES b/TRACKING.FILES
new file mode 100644
index 00..3afb468ed7
--- /dev/null
+++ b/TRACKING.FILES
@@ -0,0 +1,50 @@
+# This file contains information about source files that have been
+# copied from other sources and need to be tracked
+#
+# The file may contain lines starting with ...
+# 
+# version: of file format
+# repo: repository definition
+# file: a mapping to track files
+#
+# Note that repo: entries must come *before* file: entries
+#
+# Repository Definitions are of the following format
+# --
+# repo: name-of-source-repo git|svn https-url-of-source-repo
+#
+# name-of-source-repo:
+#   Name of source repository. The name will be used as reference in file:
+#   statements
+#
+# git|svn:
+#   Type ofsource repository
+#
+# https-url-of-source-repo:
+#   URL of source repository
+#
+# For example:
+#   repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+#
+# Mappings to track files are of the following format
+# ---
+# file: xen-file name-of-original-repo original-file commit-id
+#
+# xen-file:
+#   Xen file that needs to be tracked
+#
+# name-of-original-repo:
+#   A reference to a source repository defined by *repo* keyword
+#
+# original-file:
+#   File in original-repo from which we regularly want to merge changes
+#   into xen-file
+#
+# commit id:
+#   Last commit id of original-file that was deemed to be ok
+#   and either imported into the tree or rejected
+#
+# For example:
+#   file: xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
+
+version: 1
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 24/05/2019, 05:24, "Jan Beulich"  wrote:

>>> On 24.05.19 at 03:36,  wrote:
> --- /dev/null
> +++ b/TRACKING.FILES
> @@ -0,0 +1,50 @@
> +# This file contains information about source files that have been
> +# copied from other sources and need to be tracked
> +#
> +# The file may contain lines starting with ...
> +# 
> +# version: of file format
> +# repo: repository definition
> +# file: a mapping to track files
> +#
> +# Note that repo: entries must come *before* file: entries
> +#
> +# Repository Definitions are of the following format
> +# --
> +# repo: name-of-source-repo git|svn https-url-of-source-repo
> +#
> +# name-of-source-repo:
> +#   Name of source repository. The name will be used as reference in 
file:
> +#   statements

May I suggest another formatting change, as the colon uses now
have different meaning:

# repo:   
#
# 
#   Name of source repository. The name will be used as reference in file:
#   statements

> +# git|svn:
> +#   Type ofsource repository

Nit: Missing blank.

> +# https-url-of-source-repo:
> +#   URL of source repository

Why https? Any form of URL should be fine here.

Sure. I think Ian suggested originally.

> +# For example:
> +#   repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 

Didn't we agree on examples moving into the commit message,
or the post-commit-message area, as they'll become redundant
(and eventually stale) once we gain actual content here?

Ah yes, I had forgotten about this

Lars



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

Following the recent discussion, we had on IRC and the action I had in 
the March community call, this file provides a file format that 
enables writing an automated test to check whether files are out of sync. 

An example, what file content may look like is embedded below
repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
file: xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136

Once the file format is agree, I will write a test or script.

I also need some more correct test data, aka entries in the file from
committers looking after the following files
[Jan]
xen/arch/x86/cpu/mwait-idle.c 
[Stefano, Julien - this has to be finalized]
xen/drivers/passthrough/arm/smmu.c
xen/arch/arm/vgic/*
xen/include/asm-arm/div64.h
xen/drivers/char/meson-uart.c
xen/arch/arm/arm32/lib/*
xen/arch/arm/arm64/lib/*
xen/arch/arm/arm64/cache.S
xen/arch/arm/arm64/bpi.S
xen/include/asm-arm/system.h
xen/arch/arm/arm64/insn.c
[Others?]
xen/common/rbtree.c

Note that in some cases Linux has diverged and some Linux files have 
disappeared. 
Julien also raised the point, that in some cases only a subset of code from 
Linux Xen files was applied or that only some functions get moved across to Xen.

I believe that is entirely OK. The workflow would be in most cases that:
- We use a Linux (source) commit as a benchmark and record the commit ID
- If there is a change in Linux the test will fail
- The committer looks at the diff and either
  - Decides to ignore it and bumps the commit ID in this file
  - Decides the change is needed, integrates it into Xen and then 
bumps the commit ID in this file

Changes since v1
* Require a colon after repo:, file:, ... keywords
* Replace manual:|auto: with file: as there auto: use-case was invalid
* Added more verbose description of format

Changes since v2
* Changed some formatting
* Removed examples
* Removed references to https

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org
---
 TRACKING.FILES | 44 
 1 file changed, 44 insertions(+)
 create mode 100644 TRACKING.FILES

diff --git a/TRACKING.FILES b/TRACKING.FILES
new file mode 100644
index 00..60c47bdefb
--- /dev/null
+++ b/TRACKING.FILES
@@ -0,0 +1,44 @@
+# This file contains information about source files that have been
+# copied from other sources and need to be tracked
+#
+# The file may contain lines starting with ...
+# 
+# version: of file format
+# repo: repository definition
+# file: a mapping to track files
+#
+# Note that repo: entries must come *before* file: entries
+#
+# Repository Definitions are of the following format
+# --
+# repo: name-of-source-repo git|svn url-of-source-repo
+#
+# name-of-source-repo
+#   Name of source repository. The name will be used as reference in file:
+#   statements
+#
+# git|svn
+#   Type of source repository
+#
+# url-of-source-repo
+#   URL of source repository
+#
+# Mappings to track files are of the following format
+# ---
+# file: xen-file name-of-original-repo original-file commit-id
+#
+# xen-file
+#   Xen file that needs to be tracked
+#
+# name-of-original-repo
+#   A reference to a source repository defined by *repo* keyword
+#
+# original-file
+#   File in original-repo from which we regularly want to merge changes
+#   into xen-file
+#
+# commit id
+#   Last commit id of original-file that was deemed to be ok
+#   and either imported into the tree or rejected
+
+version: 1
-- 
2.13.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

> On 9 May 2019, at 19:43, Rich Persaud  wrote:
> 
> On May 9, 2019, at 21:28, Lars Kurth  <mailto:lars.kurth@gmail.com>> wrote:
> 
>> With regards to Windows testing we have some restrictions. We have tried 
>> several times to buy additional test licenses, but this never went anywhere 
>> (some of the VM licenses are not available for our environment, unless you 
>> bulk buy, which is very expensive). The only approach that would allow us to 
>> test against different windows versions would be to require everyone who may 
>> touch OSSTEST which is not doable.
> 
> Are the 90-day test/eval versions of Windows incompatible with OSSTEST?
> 
>   https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise 
> <https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise>
>   https://www.microsoft.com/en-us/evalcenter/ 
> <https://www.microsoft.com/en-us/evalcenter/>
> 

Actually, that's a possibility. Our use may not be compatible with the T&D's of 
the eval license though. It wasn't when we checked last time. But that can be 
checked.
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

I was hoping we'd get a list of distros + versions together, but have not had 
any input on specific distros

To make this easier, I created 
https://cryptpad.fr/pad/#/2/pad/edit/9MppkbU36LDcWT12uC6Xk3SQ/ 
Trying something else, as some people have trouble with google docs

Regards
Lars

> On 9 May 2019, at 19:28, Lars Kurth  wrote:
> 
> Hi all,
> 
> following a discussion with committers about Guest testing in OSSTEST, it 
> surfaced that we have not updated what distros we test in OSSTEST for a very 
> long time. All agreed that we should regularly review what we test against: 
> maybe at the beginning of a release cycle
> 
> In any case, currently we test against
> 
> x86 HVM guests:
>  debian-9.4.0-{i386,amd64}-CD-1.iso
>  rhel-server-6.1-i386-dvd.iso
>  win10v1703-x86.iso
>  win7-x64.iso
>  ws16-x64.iso
>  FreeBSD-10.1-CUSTOM-{i386,amd64}-20150525.raw.xz
>  Debian HVM {i386,amd64} via debian-installer netinst [1]
> 
> x86 PV guests:
>  Debian PV {i386,amd64} via debian-installer netinst [1]
> 
> ARM guests:
>  Debian PV via debian-installer netinst [1]
> 
> [1] whatever Debian release osstest itself mostly runs
> 
> So I am opening the floor to suggestions.
> 
> With regards to Windows testing we have some restrictions. We have tried 
> several times to buy additional test licenses, but this never went anywhere 
> (some of the VM licenses are not available for our environment, unless you 
> bulk buy, which is very expensive). The only approach that would allow us to 
> test against different windows versions would be to require everyone who may 
> touch OSSTEST which is not doable.
> 
> I can bring this up with the MS open source office, if there are strong 
> feelings about this and try again
> 
> Lars
> 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Project Community Call June 6th: @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,

Please propose topics by either editing the running agenda document at 
https://cryptpad.fr/pad/#/2/pad/edit/WZr2VTdfmaPdvIxjXp+cgSF- or by replying to 
the mail.
Ideally by Tuesday!
Note that I am using another sharing mechanism as per request. Let me know if 
you have difficulties

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&month=6&day=6&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=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

Re: [Xen-devel] Xen Project Community Call June 6th: @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,
a quick reminder that the call will be today
Regards
Lars

On 30/05/2019, 18:35, "Lars Kurth"  wrote:

Hi all,

Please propose topics by either editing the running agenda document at 
https://cryptpad.fr/pad/#/2/pad/edit/WZr2VTdfmaPdvIxjXp+cgSF- or by replying to 
the mail.
Ideally by Tuesday!
Note that I am using another sharing mechanism as per request. Let me know 
if you have difficulties

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&month=6&day=6&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=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 (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Hi all,

based on Stefano's and Julien's suggestion that it may make sense to merge the 
x86 and arm calls, I am willing to try. It also makes sense this time in 
particular because we are approaching freeze time.


As per request the meeting is 1 hour later than normal. Also, because there 
were NO attendees from China on the last 3 calls. For Chinese attendees: if you 
plan to attend, please confirm you are attending and we can discuss moving the 
meeting to earlier.

@Juergen, @Jan: we can discuss the timing of future meetings going forward if 
17:00-18:00 is a problem for you.

Please propose topics by either editing the running agenda document at 
https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
 or by replying to the mail. Ideally by next Tuesday!


== AOB ==

== Dial-in Information ==

   ## Future Community Call schedule
   Jan 9, Feb 13, Mar 12

   ## Meeting time
   15:00 - 16:00 UTC
8:00 -  9:00 EDT (San Francisco)
   11:00 - 12:00 EDT (New York)
   16:00 - 17:00 BST (London)
   17:00 - 18:00 CEST (Berlin)
   00:00 - 01:00 CST (Beijing)
   Further International meeting times: 
   
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=1&day=7&hour=16&min=0&sec=0&p1=224&p2=24&p3=179&p4=136&p5=37&p6=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

Best Regards
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Hi all,

as we are close to the 4.11 release, I think this means we would focus on 
release related stuff primarily. Moving the meeting a week later is probably 
not going to help re release related items.

I think it is OK if some people cannot attend the Jan meeting: We could move 
forward the Feb meeting by a week (e.g. to say the 1st Wed of Feb) and reset 
the meeting cadence. That way we can start discussing more forward looking 
items again a little earlier.

Regards
Lars

> On 3 Jan 2019, at 17:41, Artem Mygaiev  wrote:
> 
> Both myself and Alex will be at CES at this time so we won't be able to join.
> 
>  -- Artem
> From: Stefano Stabellini  <mailto:sstabell...@kernel.org>>
> Sent: Thursday, January 3, 2019 7:17:02 PM
> To: Lars Kurth
> Cc: xen-devel; committ...@xenproject.org <mailto:committ...@xenproject.org>; 
> Tamas K Lengyel; intel-...@intel.com <mailto:intel-...@intel.com>; 
> daniel.ki...@oracle.com <mailto:daniel.ki...@oracle.com>; Roger Pau Monne; 
> Christopher Clark; Rich Persaud; Brian Woods; Stefano Stabellini; Julien 
> Grall; Juergen Gross; Paul Durrant; Ji, John; Natarajan, Janakarajan; 
> dpsm...@apertussolutions.com <mailto:dpsm...@apertussolutions.com>; 
> edgar.igles...@xilinx.com <mailto:edgar.igles...@xilinx.com>; 
> davorin.mi...@aggios.com <mailto:davorin.mi...@aggios.com>; 
> robin.randh...@arm.com <mailto:robin.randh...@arm.com>; Artem Mygaiev; 
> mirela.simono...@aggios.com <mailto:mirela.simono...@aggios.com>; Stewart 
> Hildebrand; anastassios.na...@onapp.com <mailto:anastassios.na...@onapp.com>; 
> vfac...@de.adit-jv.com <mailto:vfac...@de.adit-jv.com>; Volodymyr Babchuk; 
> Matt Spencer; Jarvis Roach
> Subject: Re: Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC 
> - Call for Agenda Items
>  
> For all the folks used to attending the ARM community calls, I'll be on
> this call. Julien, won't be able to join this time, but he will join in
> the future.
> 
> On Thu, 3 Jan 2019, Lars Kurth wrote:
> > Hi all,
> > 
> > based on Stefano's and Julien's suggestion that it may make sense to merge 
> > the x86 and arm calls, I am willing to try. It also makes sense this time 
> > in particular because we are approaching freeze time.
> > 
> > 
> > As per request the meeting is 1 hour later than normal. Also, because there 
> > were NO attendees from China on the last 3 calls. For Chinese attendees: if 
> > you plan to attend, please confirm you are attending and we can discuss 
> > moving the meeting to earlier.
> > 
> > @Juergen, @Jan: we can discuss the timing of future meetings going forward 
> > if 17:00-18:00 is a problem for you.
> > 
> > Please propose topics by either editing the running agenda document at 
> > https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
> >  
> > <https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#>
> >  or by replying to the mail. Ideally by next Tuesday!
> > 
> > 
> > == AOB ==
> > 
> > == Dial-in Information ==
> > 
> >## Future Community Call schedule
> >Jan 9, Feb 13, Mar 12
> > 
> >## Meeting time
> >15:00 - 16:00 UTC
> > 8:00 -  9:00 EDT (San Francisco)
> >11:00 - 12:00 EDT (New York)
> >16:00 - 17:00 BST (London)
> >17:00 - 18:00 CEST (Berlin)
> >00:00 - 01:00 CST (Beijing)
> >Further International meeting times: 
> >
> > https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=1&day=7&hour=16&min=0&sec=0&p1=224&p2=24&p3=179&p4=136&p5=37&p6=33
> >  
> > <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=1&day=7&hour=16&min=0&sec=0&p1=224&p2=24&p3=179&p4=136&p5=37&p6=33>
> > 
> >## Dial in details
> >Web: https://www.gotomeet.me/larskurth 
> > <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
>

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Did anyone have any agenda items *NOT* related to 4.12? 
As an aside: I added the following to the agenda
* 4.12 what headline features made it
* Face 2 face to discuss a plan and implications for safety certification 
(separate e-mail will follow today)

Regards
Lars

> On 7 Jan 2019, at 18:33, Stefano Stabellini  wrote:
> 
> On Mon, 7 Jan 2019, Juergen Gross wrote:
>> On 03/01/2019 15:28, Lars Kurth wrote:
>>> Hi all,
>>> 
>>> based on Stefano's and Julien's suggestion that it may make sense to merge 
>>> the x86 and arm calls, I am willing to try. It also makes sense this time 
>>> in particular because we are approaching freeze time.
>>> 
>>> 
>>> As per request the meeting is 1 hour later than normal. Also, because there 
>>> were NO attendees from China on the last 3 calls. For Chinese attendees: if 
>>> you plan to attend, please confirm you are attending and we can discuss 
>>> moving the meeting to earlier.
>>> 
>>> @Juergen, @Jan: we can discuss the timing of future meetings going forward 
>>> if 17:00-18:00 is a problem for you.
>>> 
>>> Please propose topics by either editing the running agenda document at 
>>> https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
>>>  or by replying to the mail. Ideally by next Tuesday!
>> 
>> I'd like to discuss status of the current pending patch series:
>> 
>> Series   Author Status
>> Per-cpu tasklet  Konrad Rzeszutek Wilk  ->4.13?
>> Improvements to domain creation (v2) Andrew Cooper  ?
>> Argo (inter-VM communication) (v3)   Christopher Clark  ?
>> Core aware sched (RFC v1)Dario Faggioli ->4.13?
>> Core aware sched credit2 (RFC v1)Dario Faggioli ->4.13?
>> x86 instr emulator add AVX512 (v7)   Jan Beulichfinished?
>> HVM guest CPU topology support (RFC) Chao Gao   ->4.13?
>> Intel Trace virt. enabling (v1)  Luwei Kang ->4.13?
>> Linux stub domains (RFC v2)  Marek Marczykowski-G.  ->4.13?
>> qemu deprivilege (v4)George Dunlap  finished?
>> Improve late microcode loading (v4)  Chao Gao   ?
>> Fixes to #DB injection   Andrew Cooper  ->4.13?
>> CPUID/MSR Xen/toolstack improvements Andrew Cooper  ->4.13?
>> Improvements to domain_crash()   Andrew Cooper  ->4.13?
>> Fix VGA logdirty with altp2m (v11)   Razvan Cojocaru?
>> dom0less (v4)Stefano Stabellini ?
> 
> Dom0less is already in. "Dom0less device assignment" missed the window
> by only a couple of days (I forgot to send it in time -- too bad.)
> 
> I have another outstanding series for 4.12: "misc safety certification
> fixes".
> 
> 
>> Implement Set/Way operations (RFC)   Julien Grall   ?
> 
> Also already committed
> 
> 
>> TEE mediator support in XEN (v2) Volodymyr Babchuk  ?

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Hi all,

I noticed that I hadn't updated all the times in the meeting invite block.

> 
> == Dial-in Information ==
> 
>   ## Future Community Call schedule
>   Jan 9, Feb 13, Mar 12
> 
>   ## Meeting time
>   15:00 - 16:00 UTC

This is wrong and should read 16:00 - 17:00

>8:00 -  9:00 EDT (San Francisco)
>   11:00 - 12:00 EDT (New York)
>   16:00 - 17:00 BST (London)
>   17:00 - 18:00 CEST (Berlin)
>   00:00 - 01:00 CST (Beijing)
>   Further International meeting times: 
>   
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=1&day=7&hour=16&min=0&sec=0&p1=224&p2=24&p3=179&p4=136&p5=37&p6=33
>  
> 

Regards
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Organising a workshop to solve safety certification related questions

[Lars Kurth]

Hi all,

just before XMas Stefano (Xilinx), Alex (EPAM), Artem (EPAM), Matt (Arm), 
Guilio (Xilinx) and Munakata San (Renesas) and me had a quick call see whether 
from a Xen Project community perspective, it would be possible to make 
significant progress towards making more easily Xen Safety certifiable in 2019. 
From a technical viewpoint, I believe we are at a stage where it should be 
possible for a vendor to take a snapshot of upstream Xen and build a safety 
certifiable product on top of it (e.g. taking route 3S to achieve 26262 ASIL 
B). However, the cost of doing so today, would make it likely that vendors who 
tried to do this not share the effort and essentially lead to safety certified 
productized forks of Xen. This is undesirable for both the Xen Project and also 
for the vendors who were in the room, which is a good starting point. There are 
also a number of unresolved technical, business and process issues to make this 
happen.

To make progress on this questions, we discussed the possibility to get a few 
key people from the embedded/automotive Xen community into a room with some 
long established maintainers/committers and agree what is possible. The idea 
was for EPAM (with my help) to organise a 1-2 day workshop alongside an 
automotive event. 

Candidates discussed were
* Embedded World; Nuremberg 26-28 of Feb in Nuremberg, Germany 
* AGL all member meeting; March 5-6 in Tokyo 
* Autoshow in Detroit in April

For this to work, we would need at least 2-3 of our committers to participate 
and at least someone who is maintaining common Hypervisor code. This in my view 
disqualifies holding such a meeting outside of Europe, as most of the Xen 
maintainers are not likely to get the travel approved. We could also try and 
open some of the meetings on-line, but having a core of people in a room would 
be much more productive.

However, if we were to hold the meetings in Europe that may be easier. Options 
on the table would be:
* 28 Feb / 1 March in Frankfurt
* 21/22 Feb in Frankfurt
* Citrix could also host meetings on March 1 and Feb 22nd in Cambridge, but 
there is not enough space on both Thursday's
* Are there any other vendors who would be willing to host the meeting?

Cambridge has the advantage that most of our active committers are local (with 
the exception of Jan and Stefano). For both locations, we would have to 
restrict the meeting to 12 people.

With this in mind, I was wondering who on the committers@ list could 
participate for at least some of the meeting and if so, in which location. 
Secondly, I would like to know who else would be interesting in attending. We 
would also invite a specialist from TUV or another test institute.

What I need is 
- Raise your hands if you are interested 
- Let me know of date / location restrictions
- We could try and so some of this via video conference: would you be able to 
attend if we did open the meeting up to some remote participation

Do this either privately by replying to this mail or publicly by replying to 
the thread

In terms of agenda, we would need to discuss
1) Big picture - get everyone on one page
2) MISRA (as a placeholder for coding standard compliance)
There has not been enough progress on this in my view in 2018 and questions 
that were raised at the summit remain unresolved
3) Process and Technical implications
This would cover topics such as creating and maintaining certification artefacts
Who does this interact with the contribution workflow - aka are there any 
potential issues
Does the current master/staging approach work - if not, would we be open for a 
group of vendors to maintain official base branches for certifiable Xen based 
products
Etc.
4) Business Model
Probably a little too early for that, but I will leave this as an option
If we do get a specialist from a test institute to attend, that may be a 
worthwhile discussion to have
5) We should also discuss related issues which have been stalling, such as 
testing

Best Regards
Lars






___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Quick note: the meeting is in 15 minutes - the agenda is at 
https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit
 
<https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit>
 

> On 8 Jan 2019, at 14:34, Lars Kurth  wrote:
> 
> Hi all,
> 
> I noticed that I hadn't updated all the times in the meeting invite block.
> 
>> 
>> == Dial-in Information ==
>> 
>>   ## Future Community Call schedule
>>   Jan 9, Feb 13, Mar 12
>> 
>>   ## Meeting time
>>   15:00 - 16:00 UTC
> 
> This is wrong and should read 16:00 - 17:00
> 
>>8:00 -  9:00 EDT (San Francisco)
>>   11:00 - 12:00 EDT (New York)
>>   16:00 - 17:00 BST (London)
>>   17:00 - 18:00 CEST (Berlin)
>>   00:00 - 01:00 CST (Beijing)
>>   Further International meeting times: 
>>   
>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=1&day=7&hour=16&min=0&sec=0&p1=224&p2=24&p3=179&p4=136&p5=37&p6=33
>>  
>> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=1&day=7&hour=16&min=0&sec=0&p1=224&p2=24&p3=179&p4=136&p5=37&p6=33>
> 
> Regards
> Lars
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Save the dates: Xen Project Developer Summit 2019 - July 9 -11, Chicago, IL, USA

[Lars Kurth]

Hi all,
just a quick note to let you know that the next developer summit will be held 
in the US (in Chicago) from July 9-11. The event website including the CfP 
should be up in the next 2-3 weeks
Best Regards
Lars 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [BUG] docs: our man page generation uses http://man.he.net/ by default which causes broken links. It should be changed to point to a relative path

[Lars Kurth]

Ping!
Adding Ian Jackson specifically - we should really fix this for 4.12
Regards
Lars

> On 2 Aug 2018, at 12:24, Lars Kurth  wrote:
> 
> Hi all,
> 
> most of our man pages on pretty much all releases from 4.2 contain broken 
> links. 
> 
> For example:
> In https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html the source 
> contains:
> 
> "For more details, see L." 
> Maps onto http://man.he.net/man7/xl-numa-placement  (does not exist)
> 
> “See L<http://man.he.net/man5/xl-disk-configuration> for more details.” 
> Maps onto http://man.he.net/man5/xl-disk-configuration (does not exist)
> 
> Etc.
> 
> There seem to be two issues:
> * The root path http://man.he.net, which is incorrect
> * The resolution of filenames to man/: should be man/..html
> 
> Probably we need to feed some arguments to probably we need to feed some 
> arguments 
> to pod2html in order to generate the correct urls. See  
> https://perldoc.perl.org/pod2html.html 
> (maybe we need we need –htmldir). For our docs build, this should probably go 
> to 
> https://xenbits.xen.org/docs/unstable/man/ while for local installs to 
> ${prefix}/share/doc/xen/html/man or something like it.
> 
> I had a look to see whether I can fix this, but that seems a little too 
> complex for me
> 
> Regards
> Lars
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen 4.12 Development Update

[Lars Kurth]

Hi Juergen,

> On 14 Jan 2019, at 10:13, Juergen Gross  wrote:
> 
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.12 so that people have an idea what is going on and
> prioritise accordingly.
> 
> You're welcome to provide description and use cases of the feature you're
> working on.
> 
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release about every 8 
> months.
> The upcoming 4.12 timeline are as followed:
> 
> * Last posting date: December 14th, 2018
>  Last posting date for patches touching ARM code: December 1st, 2018
> * Hard code freeze: January 11th, 2019
>  Hard code freeze for patches touching ARM code: December 21st, 2018
> --> we are here
> * RC1: TBD
> * Release: March 7th, 2019
> 
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.12 must be posted initially no later than the
> last posting date and finally no later than the hard code freeze. All
> patches posted after that date will be automatically queued into next
> release.
> 
> RCs will be arranged immediately after freeze.

We should start planning on a Test Day schedule.

> We recently introduced a jira instance to track all the tasks (not only big)
> for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.
> 
> Some of the tasks tracked by this e-mail also have a corresponding jira task
> referred by XEN-N.
> 
> I have started to include the version number of series associated to each
> feature. Can each owner send an update on the version number if the series
> was posted upstream?
> 
> = Projects =
> 
> == Hypervisor == 
> 
> *  Improvements to domain creation (v2)
>  -  Andrew Cooper
> 
> *  Argo (inter-VM communication) (v3)
>  -  Christopher Clark
> 
> *  Core aware scheduling (RFC v1)
>  -  Dario Faggioli
> 
> *  Core aware scheduling for credit2 (RFC v1)
>  -  Dario Faggioli
> 
> === x86 === 
> 
> *  hypervisor x86 instruction emulator additions for AVX512 (v7)
>  -  Jan Beulich
> 
> *  qemu deprivilege (v4)
>  -  George Dunlap
> 
> *  Fixes to #DB injection
>  -  Andrew Cooper
> 
> *  CPUID/MSR Xen/toolstack improvements
>  -  Andrew Cooper
> 
> *  Improvements to domain_crash()
>  -  Andrew Cooper
> 
> === ARM === 
> 
> == Completed == 
> 
> *  guest resource mapping
>  -  Paul Durrant
> 
> *  PV-only hypervisor
>  -  Wei Liu
> 
> *  HVM-only hypervisor
>  -  Wei Liu
> 
> *  Make credit2 scheduler the default
>  -  George Dunlap
> 
> *  Grub2: Support PVH guest boot
>  -  Juergen Gross
> 
> *  Fix VGA logdirty related display freezes with altp2m
>  -  Razvan Cojocaru
> 
> *  dom0less (boot multiple domains from device tree)
>  -  Stefano Stabellini
> 
> *  Implement Set/Way operations
>  -  Julien Grall

@Stefano:
Didn't the ARM KCONFIG stuff go in *after* 4.11? If so, this should probably be 
added. 
Can't recall the series name

Also, I think the Aggios changes went in after 4.11 was released also.
The series was "xen/arm64: Suspend preconditions and CPU hotplug fixes"

@ALL: also, for any major new features and/or enablers, we should look at the 
docs and make sure they are in place and up-to-date, that SUPPORT.md is updated 
and that any worthy/big enough features are listed. Also, if you contributed a 
larger series/feature and it is not on this list, please let us know.  

Thank you to everyone contributing to the project

Best Regards
Lars 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 04/15] argo: init, destroy and soft-reset, with enable command line opt

[Lars Kurth]

Adding Juergen,

to make sure he is aware of the discussion, as this is an excellent summary of 
the status of this series.

> On 14 Jan 2019, at 14:46, Wei Liu  wrote:
> 
> Hi all
> 
> The locking scheme seems to be remaining sticking point. The rest are
> mostly cosmetic issues (FAOD, they still need to be addressed).  Frankly
> I don't think there is enough time to address all the technical details,
> but let me sum up each side's position and see if we can reach an
> amicable solution.

snip

> To unblock this, how about we make Christopher maintainer of Argo? He
> and OpenXT will be on the hook for further improvement. And I believe it
> would be in their best interest to keep Argo bug-free and eventually
> make it become supported.
> 
> So:
> 
> 1. Make sure Argo is self-contained -- this requires careful review for
>   interaction between Argo and other parts of the hypervisor.
> 2. Argo is going to be experimental and off-by-default -- this is the
>   default status for new feature anyway.
> 3. Make Christopher maintainer of Argo -- this would be a natural thing
>   to do anyway.
> 
> Does this work for everyone?

I think this is a good way forward. Thank you Wei for putting this mail 
together.

Best Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Preparing for Xen Project GSoC applications : Deadline Feb 6

[Lars Kurth]

Hi all, 

I will be applying as a mentoring organisation for GSoC again this year: the 
application deadline is Feb 6 and by then we need to have 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects in order. Given that 
we didn't get in last year, there is a 50/50 chance we get in this year.

Everyone on the CC list has projects listed on 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects

Our project list is a little old and stale and that shows: we do need to bring 
this up-to-date and freshen it up with new projects. I believe that the Mini-OS 
and Unikraft projects need looking at. And we may have some new sensible 
projects in the Hypervisor itself. Mindy already agreed to go over the Mirage 
OS list.

If you want to withdraw your project: please let me know and I delete it: but 
let me know WHY you want to withdraw. E.g. is it complete

@Doug, @Comitters
Re 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Code_Standards_Checking_using_clang-format
Given that there has been some work on clang-format by EPAM, which no-one has 
looked at I am tempted to throw this out or re-do the project. Aka, die a next 
phase which includes integrating the tool into our workflow. But that may be 
too hard
Any views?

Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] docs: Fix links in html generation of man pages

[Lars Kurth]

> On 15 Jan 2019, at 17:07, Ian Jackson  wrote:
> 
> Anthony PERARD writes ("Re: [PATCH 2/2] docs: Fix links in html generation of 
> man pages"):

snip

> Anyway, this patch of yours is a big improvement, so:
> 
> Acked-by: Ian Jackson 
> 
> I think linkifying that one missing link is a `nice to have' and can
> be done now or later as yo like.
> 
> Ian.


Indeed it is. Thank you for fixing this
Regards
Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Organising a workshop to solve safety certification related questions

[Lars Kurth]

> On 16 Jan 2019, at 12:16, George Dunlap  wrote:
> 
> On 1/8/19 5:59 PM, Lars Kurth wrote:
>> What I need is 
>> - Raise your hands if you are interested 
>> - Let me know of date / location restrictions
>> - We could try and so some of this via video conference: would you be able 
>> to attend if we did open the meeting up to some remote participation
> 
> I'm interested.  All the dates mentioned should work for me.
> 
> -George

Hi all,

to summarise!

We have a good number of people and organisations interested from pretty one 
everyone on the list, but it seems the dates won't work for most people. 
Location wise: Germany (Frankfurt) and/or UK (Cambridge) work for most, except 
for representatives from Dornerworks and Starlab, who would dial in for some of 
the meetings 
There seems to be a slight bias for Cambridge, as we have most of our 
maintainers there. 

Automotive vendors would be happy to align with automotive meetings/events 
(even in Japan), but that won't work for the committers as they won't normally 
be able to travel. 
I also have two organisations which could potentially host in Cambridge and one 
in Germany (Frankfurt). But the venue depends partly on the dates. This tells 
me, that we should choose either Frankfurt or Cambridge for the event.

In terms of numbers we are roughly looking at 10-12 who could attend 
physically, but it could be more

To move forward, I thought I would expend the time horizon a little bit via the 
following doodle poll: https://doodle.com/poll/anvfr2hk2t8gy9a8 
<https://doodle.com/poll/anvfr2hk2t8gy9a8>
Note that you can specify suboptimal dates by clicking twice: also, if you have 
any constraints on location, etc. feel free to make use of the commenting 
feature.

I will be in the US mid-March and thus excluded these dates. I also excluded 
March 28/29: because of Brexit, it is possible that there would be some travel 
chaos at least in the UK. 

Regards
Lars



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Preparing for Xen Project GSoC applications : Deadline Feb 6

[Lars Kurth]

Thank you Felipe
I went through and updated the Verified dates and also changed the date of 
insert for "New Platform Support" and "Go Language Support" as these were 
different enough from what was there before
Regards
Lars

> On 16 Jan 2019, at 13:10, Felipe Huici  wrote:
> 
> Hi Lars,
> 
> We've updated the description of the projects related to Unikraft, please let 
> us know if you need anything else from us.
> 
> Thanks,
> 
> -- Felipe
> 
> 
> Dr. Felipe Huici
> Chief Researcher, Systems and Machine Learning Group
> NEC Laboratories Europe GmbH
> Kurfuerstenanlage 36, D-69115 Heidelberg
> Tel.  +49
> (0)6221 4342-241
> Fax:  +49
> (0)6221 4342-155
> 
> e-mail:
> felipe.hu...@neclab.eu
> ====
> Registered at Amtsgericht Mannheim, Germany, HRB728558
> 
> On 15.01.19, 14:33, "Lars Kurth"  wrote:
> 
>Hi all, 
> 
>I will be applying as a mentoring organisation for GSoC again this year: 
> the application deadline is Feb 6 and by then we need to have 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects in order. Given 
> that we didn't get in last year, there is a 50/50 chance we get in this year.
> 
>Everyone on the CC list has projects listed on 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects
> 
>Our project list is a little old and stale and that shows: we do need to 
> bring this up-to-date and freshen it up with new projects. I believe that the 
> Mini-OS and Unikraft projects need looking at. And we may have some new 
> sensible projects in the Hypervisor itself. Mindy already agreed to go over 
> the Mirage OS list.
> 
>If you want to withdraw your project: please let me know and I delete it: 
> but let me know WHY you want to withdraw. E.g. is it complete
> 
>@Doug, @Comitters
>Re 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Code_Standards_Checking_using_clang-format
>Given that there has been some work on clang-format by EPAM, which no-one 
> has looked at I am tempted to throw this out or re-do the project. Aka, die a 
> next phase which includes integrating the tool into our workflow. But that 
> may be too hard
>Any views?
> 
>Regards
>Lars
> 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Organising a workshop to solve safety certification related questions

[Lars Kurth]

Hi all,

it looks as if March 25/26 in Frankfurt or Cambridge is the best option. For 
Matt, this would mean that he can only attend the first day, but I believe this 
would be OK. Maybe Robin can attend the second day, instead of Matt. Before we 
finalise the dates, I will need to secure the meeting space. I will be able to 
do this in the next few days and will send an update as soon as this is done.

Note that we had a few people on this list which have replied to me privately. 
Please let me know privately or publicly whether March 25/26 would be suitable 
for you. We can in parallel work on the agenda.
 
Best Regards
Lars

> On 16 Jan 2019, at 13:09, Lars Kurth  wrote:
> 
> 
> 
>> On 16 Jan 2019, at 12:16, George Dunlap > <mailto:george.dun...@citrix.com>> wrote:
>> 
>> On 1/8/19 5:59 PM, Lars Kurth wrote:
>>> What I need is 
>>> - Raise your hands if you are interested 
>>> - Let me know of date / location restrictions
>>> - We could try and so some of this via video conference: would you be able 
>>> to attend if we did open the meeting up to some remote participation
>> 
>> I'm interested.  All the dates mentioned should work for me.
>> 
>> -George
> 
> Hi all,
> 
> to summarise!
> 
> We have a good number of people and organisations interested from pretty one 
> everyone on the list, but it seems the dates won't work for most people. 
> Location wise: Germany (Frankfurt) and/or UK (Cambridge) work for most, 
> except for representatives from Dornerworks and Starlab, who would dial in 
> for some of the meetings 
> There seems to be a slight bias for Cambridge, as we have most of our 
> maintainers there. 
> 
> Automotive vendors would be happy to align with automotive meetings/events 
> (even in Japan), but that won't work for the committers as they won't 
> normally be able to travel. 
> I also have two organisations which could potentially host in Cambridge and 
> one in Germany (Frankfurt). But the venue depends partly on the dates. This 
> tells me, that we should choose either Frankfurt or Cambridge for the event.
> 
> In terms of numbers we are roughly looking at 10-12 who could attend 
> physically, but it could be more
> 
> To move forward, I thought I would expend the time horizon a little bit via 
> the following doodle poll: https://doodle.com/poll/anvfr2hk2t8gy9a8 
> <https://doodle.com/poll/anvfr2hk2t8gy9a8>
> Note that you can specify suboptimal dates by clicking twice: also, if you 
> have any constraints on location, etc. feel free to make use of the 
> commenting feature.
> 
> I will be in the US mid-March and thus excluded these dates. I also excluded 
> March 28/29: because of Brexit, it is possible that there would be some 
> travel chaos at least in the UK. 
> 
> Regards
> Lars
> 
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Project Developer and Design Summit 2019: Cfp and Registration Open Now

[Lars Kurth]

Dear Community Members,

starting today, registration officially opens for The Xen Project Developer & 
Design Summit. This year’s Summit, taking place from July 9 through 11 in 
Chicago, will bring together the Xen Project community of developers and power 
users to share ideas, latest developments, and experiences, as well as offer 
opportunities to plan and collaborate on all things Xen Project. You can find 
more information at https://events.linuxfoundation.org/events/xensummit-2019/

If you’d like to present at the Summit and have a topic that you’d like to 
submit, the Call For Proposals is open now and will close April 12, 2019.

Last but not least, we have many opportunities to support the Summit via 
sponsorships. For information regarding registration, speaking opportunities 
and sponsorships, head over the event website and learn more!

Best Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] tboot: remove maintainers and declare orphaned

[Lars Kurth]

> On 26 Jul 2019, at 08:17, Roger Pau Monné  wrote:
> 
> On Thu, Jul 25, 2019 at 03:08:07PM -0400, Rich Persaud wrote:
>> (cc Intel and tboot-devel)
>> 
>> Hi Roger,
>> 
>> Thanks for your interest in documenting the status of maintenance for Intel 
>> TXT support in Xen.  Intel TXT and Xen are deployed in production today by 
>> OpenXT and QubesOS for boot integrity.  Xen was a pioneering adopter of 
>> DRTM, almost a decade ago, but mainstream enterprise computing is now 
>> catching up with the May 2019 release of Windows 10 SystemGuard.  It would 
>> be nice to avoid "orphaning" one of Xen's competitive advantages in 2019.
> 
> Thanks for the feedback! Just to be clear, this is not a plan to
> remove the tboot code from Xen in any way, it's just a IMO needed step
> in order to reflect the current maintainership status of the code, and
> likely a way to move forward, please see below.


>>> On Jul 25, 2019, at 09:51, Roger Pau Monne  wrote:
>>> 
>>> Gang Wei Intel email address has been bouncing for some time now,
>> 
>> Gang Wei's replacement is Lukasz Hawrylko, who posted on March 6, 2019:
>> https://lists.gt.net/xen/devel/546401
>> 
>> Could you include Lukasz patch, along with Julien's requested formatting 
>> changes, in your update to the MAINTAINERS file?
> 
> I think it would be better if Lukasz could resend his patch, now that
> the section entry is orphaned we can add/remove reviewers and
> maintainers without being blocked.

I added Tamas who I believe works for Intel in the security area and maybe he 
can connect some dots here. I believe that Intel's security organisation is 
entirely different from our normal interfaces with Intel, so he may be able to 
help. 

@Lukasz: could you re-send the patch related to maintainership after the patch 
has been applied? Regarding Jan's and Julien's concerns about awarding 
maintainership straight away. We tend to ask prospective maintainers who don't 
have a track record of reviewing code in the community to start as reviewers. 
An example of this is the VM EVENT, MEM ACCESS and MONITOR component where 
Razvan is handing over maintainership to two other bitdefender staff members. 
In practice, this makes not a lot of difference if you review contributions to 
TXT. 

Regarding removing Shane Wang as maintainer, the case for this is somewhat 
stronger than simply not replying to [0]. The last mail Shane sent to 
xen-devel@ was in 2011. This - according to his LinkedIn profile - relates to a 
career change towards becoming a manager and being responsible for components 
that are not related to virtualisation. Shane should probably have stepped down 
as a maintainer pro-actively, but we normally don't remove maintainers unless 
there is a problem. Clearly the lack of a responsive maintainer is now a 
problem: we already have been unable to instate Lukasz as maintainer in March 
for that reason as technically an ACK from an existing maintainer is needed.

@Roger: this should be recorded in the commit message. I would also suggest you 
refer to the thread related to Lukasz taking over maintainership, which was 
essentially blocked because Gang had probably sent the maintainership change 
request too late and couldn't ACK it because he probably didn't have access to 
his Intel email address anymore.

So I think removing Shane is fair enough. In particular if it helps instate a 
replacement maintainer. 

>> As a new Xen maintainer and contributor, Lukasz may not yet be familiar with 
>> the procedures and practices of the Xen community.  We can welcome his new 
>> maintainership role without dropping support for a feature, that (a) he is 
>> maintaining, (b) is used by Xen.
> 
> Sure, my plan is to declare the support orphaned, so that Lukasz (or
> anyone who has interest in this code) can be added as a reviewer
> afterwards without us being blocked on an Ack from Shane Wang, who is
> unresponsive (as per the thread pointed to in the commit message).


>>> and
>>> the other maintainer is non-responsive to patches [0], so remove
>>> maintainers and declare INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>>> orphaned.
>>> 
>>> [0] 
>>> https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg00563.html
>> 
>> Since we have at least one Intel maintainer, Lukasz, the feature need not be 
>> orphaned.  If Shawn is not responding to the request to confirm Lukasz as 
>> maintainer, the Xen community has multiple communication channels with 
>> Intel.  Pragmatically, a review of the tboot-devel archives shows that 
>> Lukasz is working on tboot development.  
> 
> The orphaned step is IMO needed in order to move forward and add a new
> reviewer/maintainer. Without removing the current maintainers and
> declaring it orphaned we would be blocked on an Ack from Shane Wang in
> order to add or remove maintainers. Removing current maintainers and
> adding Lukasz in the same patch would still require an Ack from the
> current owners.

@All: we probably need to look at 

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

[Lars Kurth]

On 26/07/2019, 16:12, "Julien Grall"  wrote:

Hi Viktor,

On 26/07/2019 15:58, Viktor Mitin wrote:
> On Fri, Jul 19, 2019 at 11:37 AM Julien Grall  
wrote:
>>
>> Hi Tamas,
>>
>> On 18/07/2019 18:22, Tamas K Lengyel wrote:
  - Line 139: The { are commonly on the same line as struct or 
definition.
>>>
>>> According to CODING_STYLE that's not how it should be.
>>
>> I guess you refer to the section "Bracing". If so, I think we don't 
follow the
>> CODING_STYLE for struct or definition.
>>
>> I have to admit that for this case, I always have to look at other usage 
in the
>> code because I tend to put the { on a newline.
>>
>> I was going to say that there may be some cases where it makes sense to 
keep {
>> on the same line. For instance:
>>
>>  { a, b, c, d },
>>  { e, f, g, h },
>>
> 
> All the rules should be stated in CODING_STYLE explicitly.
> In other cases, it cannot be automated with future proves why it works
> this or that way.

This is not very constructive to send on multiple different threads "this 
should 
be explicitly be in the CODING_STYLE". Most of the people in CC are aware 
this 
is an issue.

But the problem here is codifying those styles. This often results in a lot 
of 
discussions because a lot is a matter of taste. In other there are no 
answers to 
the patches.

What we need is someone to drive this effort and make sure we make some 
progress.

Also, trying to codify all the unwritten styles is probably going to be 
difficult. Instead, I would suggest to start from an existing coding style 
that 
is very close to Xen (maybe BSD?).

OK. Maybe this is something I should drive, if there is in fact some sort of 
agreement that this makes sense.

I agree that codifying the styles is problematic, as it encourages bike 
shedding. Maybe this is something 
where we could try something vote based, aka make a list of codified rules. 
Have everyone vote in the usual
way of -2 ... +2 on it.

Also, we can't implement checking tools, if the styles are not documented. 
Checking tools should free up
reviewer time.

Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] XCP-ng subproject proposal

[Lars Kurth]

Hi everyone,

adding committers, who would need to vote for or against the proposal. The 
title probably does not need an RFC, which is why no-one looked at it so far

I think this is a great idea and I would want to welcome XCP-ng into the 
project: with this in mind, I vote +1

Lars


> On 22 Jul 2019, at 17:25, Olivier Lambert  wrote:
> 
> Hello everyone,
> 
> Following up on discussions that we had at the last Xen summit, we’re 
> submitting a Xen subproject proposal, regarding XCP-ng project 
> (https://xcp-ng.org ). Feel free to give your feedback!
> 
> Regards,
> 
> Olivier Lambert and XCP-ng team
> 
> 
> # XCP-ng proposal
> 
> ## The Project
> 
> XCP-ng is a turn-key virtualization platform based on the Xen Hypervisor, 
> using existing Xen Project tools (XAPI). It's built from Xenserver source, 
> improved and maintained by both passionate individuals and companies. The 
> result is a completely free and Open Source solution available for everyone.
> 
> Thanks to a very successful Kickstarter campaign as well as backing from 
> various companies, the project doesn't require any further funds and isn't 
> seeking monetary contributions.
> 
> We believe forming a Xen sub-project within the Linux Foundation has the 
> potential to bring further companies and contributors into the Xen Project as 
> a whole, as well as demonstrate our dedication to open source. XCP-ng has 
> already displayed its ability to draw new users into the Xen virtualization 
> ecosystem. For new users, utilizing Xen from scratch can be daunting. XCP-ng 
> offers a way to solve this problem by drawing end-users more closely into the 
> Xen Project and providing an easy route for prospective Xen users to get 
> started with Xen. This is an area where Xen has been trailing KVM for a long 
> time. Hosting XCP-ng within the Xen Project provides a route to level the 
> playing field. It would also enable the Xen Project to leverage XCP-ng 
> success stories for the benefit of the Xen Project as a whole.
> 
> ## The Mission
> 
> Our goal is to continue development of XCP-ng while building a large 
> community of contributors to XCP-ng. We also expect an increase of 
> contributions to XAPI as well as the Xen Project. Through large community 
> involvement and contributions we have already turned XCP-ng into a stable 
> hypervisor platform that is used in small and large enterprise deployments.
> 
> ## Upstream first, fully Open Source
> 
> Vates and XCP-ng have started to work with a number of academic organizations 
> with the aim to fund and develop feature improvements and new features that 
> benefit the whole Xen Project ecosystem (including the Hypervisor and XAPI). 
> We follow an upstream first philosophy, which is possible because of the fast 
> release cycle of XCP-ng and expect to become a long-term contributor to XAPI 
> and the Hypervisor project.
> 
> Besides contributions, we believe that an XCP-ng which is part of the Xen 
> Project will deliver other benefits:
> 
> * Bring passionate and verbal XCP-ng users closer to the Xen Project
> * Bring more publicity to the Xen Project: currently we have the XCP-ng blog, 
> newsletter and success stories, which we are willing to share with the Xen 
> Project
> 
> With an incredibly active forum, IRC, and github, we are always looking for 
> more contributors to the project. We also believe in giving back to the open 
> source community via contributions to upstream projects, and we believe 
> becoming a Xen Project member will help in our ability to do so. To further 
> our dedication to open source, Vates SAS, the company with the most active 
> contributions to XCP-ng currently, is in the process of becoming a Linux 
> Foundation member.
> 
> ## How we differ from existing platforms
> 
> Our vision is to maintain XCP-ng as a complete easy-to-use hypervisor 
> solution similar to existing full-stack solutions. Where we differ is our 
> dedication to the open source mindset. We have no licensing system or license 
> restrictions, all pieces of the platform are free to use. Simultaneously, we 
> encourage community involvement and have merged many community contributions 
> already.
> 
> ## Infrastructure
> 
> The infrastructure will be primarily managed by Vates, with multiple 
> companies in partnership (mainly hosting companies owning DC real estate). 
> Access and resources can be given for people interested in becoming 
> maintainers.
> 
> We would also like to expand the very active XCP-ng forum to also cover Xen 
> and XAPI, providing a modern user friendly interface for users to discuss the 
> hypervisor and related parts with dedicated sections. This will help to 
> centralize much Xen & XAPI discussion in a place that is easier for casual 
> users to find than a mailing list.
> 
> ## Security
> 
> XCP-ng has a dedicated email for security feedback (secur...@xcp-ng.org 
> ) and is already a member of the Xen 
> pre-discl

Re: [Xen-devel] [PATCH] Intel TXT: add reviewer, move to Odd Fixes state

[Lars Kurth]

> On 30 Jul 2019, at 11:08, George Dunlap  wrote:
> 
> On 7/30/19 10:54 AM, Julien Grall wrote:
>> Hi Jan,
>> 
>> On 30/07/2019 10:05, Jan Beulich wrote:
>>> On 30.07.2019 10:54, Julien Grall wrote:
 On 7/30/19 9:29 AM, Jan Beulich wrote:
> On 30.07.2019 08:56, Lukasz Hawrylko wrote:
>> Support for Intel TXT has orphaned status right now because
>> no active maintainter is listed. Adding myself as reviewer
>> and moving it to Odd Fixes state.
>> 
>> Signed-off-by: Lukasz Hawrylko 
>> ---
>> MAINTAINERS | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 89a01b710b..ca300e87c8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -240,7 +240,8 @@ S:Maintained
>>   F:tools/golang
>>   INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>> -S:Orphaned
>> +R:Lukasz Hawrylko 
>> +S:Odd Fixes
> 
> I guess we should give it a few days for objections to be raised
> against this slightly inconsistent state, but I think that's the
> best way to express the current state of things (hence my
> suggestion to this effect). If no objections turn up, I've queued
> this onto my to-be-committed list.
 
 I have some objections regarding the process itself... On the first
 version of this patch, it was pointed out that the e-mail shouldn't
 be sent with disclaimer. This is now the third version and the
 disclaimer is still present.
>>> 
>>> Okay, I must have missed both earlier requests to this effect. I've
>>> gone back to the list archives though, and I couldn't find any such
>>> request either from July or June. Therefore ...
>> 
>> The first version was sent from March [1].
>> 
>>> 
 Technically, no patch should be applied when there are a disclaimer.
>>> 
>>> ... I'd also like to ask for the background of this. It would never
>>> have occurred to me that I should pay attention to possible
>>> disclaimers or alike on patch submissions.
>> 
>> The disclaimer tell you this patch may contain confidential information
>> and you are not allowed to distribute it... While I agree this makes no
>> sense for public ML, we still have to stay on the safe side. How do you
>> know this was not sent by mistake? Note that this question makes little
>> sense on MAINTAINERS file...
>> 
>> In general, I am following Greg KH advice here [2] and refrain to answer
>> any e-mail with disclaimer. I would actually advocate xen-devel to
>> completely block those e-mails.
> 
> I think "refraining from answering" and "blocking from the list" is a
> bit too strong: after all, the disclamer does say "may", and it should
> be pretty clear that the "intended recipients" includes anyone on xen-devel.
> 
> But for code itself, which will end up being used in the products of
> large corporations with deep pockets, I agree should be absolutely clear
> of legal doubt; as such, having such a disclaimer on the patches should
> be disallowed.  We get lots of patches from Intel folks which don't have
> the disclaimer at the bottom.
> 
> Sorry to delay this simple change yet again.

+full committers list and Juergen 

OK. We should have a separate discussion related to disclaimers: make a formal 
decision and afterwards document it in the contribution workflow. I agree that 
this makes sense, and this has been raised by Julien in the past privately 
related to questions on xen-devel@. It then turned out that Arm folks from 
China have consistently used disclaimers on contributions to mini-os and 
unikraft. This has stopped now, which is to Julien's credit. I suggested than 
that Julien should raise this issue formally as a policy change, which never 
happened.

I do not believe that we should block any patches from being applied due to 
disclaimers in absence of an agreed policy. Contributors sign a DCO and that 
may well override a disclaimer (we do not have access to the legal advice that 
Greg KH refers to). If there was a serious legal issue, the LF would have 
contacted all of its projects. And I also could not find any public reference 
to such an issue. This definitely something where the Advisory Board should 
have some input.

And in particular this patch also contains no code and should not be blocked on 
these grounds.

@Lukasz: please take note of this issue for the next time round. It should be 
easy enough to disable the disclaimer when sending to certain lists

To move forward: 
* There should be a policy discussion
* There should be AB input
* The outcome should be documented in 
https://xenproject.org/help/contribution-guidelines/ 
 and the git contribution 
workflow

Lars



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ANNOUNCE} Call for agenda items for Aug 1st Community Call @ 15:00 UTC

[Lars Kurth]

Hi all,
the proposed agenda is in 
https://cryptpad.fr/pad/#/2/pad/edit/arfa2Pr3D2uIuEN3EWNTdOVT/
Alternatively, you can reply to this mail directly
Agenda items appreciated by tomorrow
Regards
Lars
P.S.: If you want to be added or removed from the CC list please reply privately

== Dial-in Information ==

 ## Meeting time
 15:00 - 16:00 UTC
 Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=8&day=1&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=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

Re: [Xen-devel] [PATCH] Intel TXT: add reviewer, move to Odd Fixes state

[Lars Kurth]

> On 31 Jul 2019, at 12:52, Julien Grall  wrote:
> 
>> To move forward:
>> * There should be a policy discussion
> 
> How should I raise it? Do you want a patch again contribution-guidelines?

I think we should start with an e-mail thread with an appropriate title on 
xen-devel@ (CCing committers@) outlining 
* What the proposal is and why it is important
  - How we document it is secondary and I am happy to pick this up after there 
is agreement 
* How it would be implemented - e.g. if the proposal was to reject e-mails with 
a disclaimer, we need to have a mechanism that does this reliably and also 
informs senders why a mail was not posted. We wouldn't want xen-devel@ to 
become a black hole, where stuff from some people gets lost without

It then would have to go through a vote as normal. You may want to have a chat 
to Ian Jackson on IRC: he has some opinions and experience that is applicable

I just agreed with Ian, that there will be a similar discussion related to the 
2 step process to change maintainers via unsupported status, which also was 
highlighted in this thread. Although this can probably just be a patch to 
MAINTAINERS

Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Coding style and clang-format

[Lars Kurth]

> On 31 Jul 2019, at 12:43, Viktor Mitin  wrote:
> 
> On Wed, Jul 31, 2019 at 2:25 PM Julien Grall  > wrote:
>> 
>> 
>> 
>> On 31/07/2019 12:16, Viktor Mitin wrote:
>>> On Mon, Jul 29, 2019 at 3:35 PM Julien Grall  wrote:
 On 7/29/19 1:21 PM, Viktor Mitin wrote:
> On Mon, Jul 29, 2019 at 1:49 PM Julien Grall  wrote:
>> On 7/29/19 10:13 AM, Viktor Mitin wrote:
>>> On Fri, Jul 26, 2019 at 3:50 PM Julien Grall  
>>> wrote:
 
 *
 
 -/* See linux
 Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
 +/* See linux
 + * 
 Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
 
 Multi-lines comment on Xen are using
 /*
 * Foo
 * Bar
 */
>>> 
>>> See my comment about clang-format supports only comments indentation 
>>> for now.
>> 
>> I saw it and I will reply here for simplicity. Having a automatic
>> checker that will do the wrong things is not ideal.
>> 
>> Imagine we decide to use this checker as a part of the commit process.
>> This means that the code will be modified to checker coding style and
>> not Xen one.
> 
> Well, you are right. Even more, unfortunately, there is no such coding
> style as 'bsd' in clang-format.
> So 'xen' clang-format style is based on the 'llvm' style.
 
 Do you have a pointer to the LLVM style?
>>> 
>>> Sure, see the next links:
>>> https://github.com/viktor-mitin/xen-clang-format-example/blob/master/.clang-format_llvm
>>> https://github.com/viktor-mitin/xen-clang-format-example/blob/master/.clang-format_xen
>> 
>> That's clang-format configuration not a write-up easily readable by human. 
>> It is
>> also does not say what will happen for the rest of the things not configured 
>> (if
>> there are any).
> 
> Here is Clang-Format Style Options documentation:
> https://clang.llvm.org/docs/ClangFormatStyleOptions.html 
> 
> 
> And LLVM Coding Standards documetation:
> https://llvm.org/docs/CodingStandards.html#introduction 
> 
> 
> Unfortunately, it seems it does not answer "what will happen for the
> rest of the things not configured (if there are any)"...
> 
> 
>> 
>>> 
 
 As I pointed out in a different thread, it woudl be easier to start from
 an existing coding style (LLVM, BSD...) and decide whether you want to
 fully adopt it or make changes.
 
 So someone needs to be pick one and look at the difference in style with
 Xen. It seems you already done that job as you tweak it for Xen. Do you
 have a write-up of the differences?
>>> 
>>> Yes, it is done exactly this way you mentioned. New 'xen' format style
>>> is based on 'llvm'.
>> 
>> Can you give a link to this write-up in a human readable way?
> 
> The summary I wrote in the original mail in this thread describes what
> was done based on 'llvm' coding style of clang-format.
> I'm putting it here with update: added BreakStringLiterals thing to be fixed.
> 
> Summary of the changes:
> - Added 3 new formatting styles to cover all the cases mentioned in
> Xen coding style document: Xen, Libxl, Linux;
> - Added list of the files and corresponding style name mappings;
> - Added indentation according to Xen coding style;
> - Added white space formatting according to Xen coding style;
> - Added bracing support exception for do/while loops;
> 
> Added to clang-format, however, probably this logic should be moved to
> python part (see known clang-format limitations above):
> - Braces should be omitted for blocks with a single statement. Note:
> these braces will be required by MISRA, for example, so it is probably
> worth adding such a requirement to the coding style.
> - Comments format requirements. Note: //-style comments are defined in
> C99 as well, and not just in the case of C++. C99 standard is 20-years
> old…
> 
> To be added:
> - Emacs local variables. Open points: Why to keep emacs local
> variables in Xen code? What about other editors' comments (vim)?
> - Warning to stderr in the case when ‘unfixable’ line/s detected.
> 
> To be fixed:
> - Max line length from 80 to 79 chars;
> - Disable // comments;
> - Set BreakStringLiterals to false (not explicitly covered by Xen
> coding style document for now)
> 
>> 
>>> 
 
 I am not sure why clang-format decided to format like that. Do you 
 know why?
>>> 
>>> The reason is that there are two strings in one line. It would not
>>> change it if it were
>>> not "arm,psci-1.0""\0", but "arm,psci-1.0\0".
>> 
>> I would like to see the exact part of the clang-format coding style
>> documentation that mention this requirements... The more that in an
>> example above (copied below for simplicity), there are two st

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

[Lars Kurth]

> On 31 Jul 2019, at 17:54, Viktor Mitin  wrote:
> 
> Hi All,
> 
> On Wed, Jul 31, 2019 at 7:45 PM Andrew Cooper  
> wrote:
>> 
>> On 31/07/2019 17:24, Volodymyr Babchuk wrote:
>>> There are coding style rules that are widely accepted by community,
>>> but newer were formalized in the document. Notable example is the
>>> question on how function arguments and parameters should be indented
>>> when they do not fit into one line.
>>> 
>>> This question was raised multiple times lately, mostly because of
>>> ongoing efforts to create Xen coding style formatting tool and because
>>> of new community members, who are not aware of such unwritten rules.
>>> 
>>> Actually, this rule is already implicitly defined in the document by
>>> defining emacs coding style: 'c-file-style: "BSD"'. In this mode emacs
>>> lines up function arguments under the first argument. Naturally, most
>>> of Xen code is written in this style.
>>> 
>>> So, lets state the obvious and fix this rule explicitly.
>>> 
>>> Signed-off-by: Volodymyr Babchuk 
>>> ---
>>> CODING_STYLE | 14 ++
>>> 1 file changed, 14 insertions(+)
>>> 
>>> diff --git a/CODING_STYLE b/CODING_STYLE
>>> index 6cc5b774cf..6479215a15 100644
>>> --- a/CODING_STYLE
>>> +++ b/CODING_STYLE
>>> @@ -53,6 +53,20 @@ Line Length
>>> Lines should be less than 80 characters in length.  Long lines should
>>> be split at sensible places and the trailing portions indented.
>>> 
>>> +For multiline function declaration and call each new line should be
>>> +aligned with the first the parameter or argument. e.g.:
>>> +
>>> +void my_function_with_long_name(struct lengthy_struct_name *struct1,
>>> +struct lengthy_struct_name *struct2,
>>> +struct lengthy_struct_name *struct3);
>>> +
>>> +or
>>> +
>>> +function_with_so_many_params(wordy_parameter1, wordy_parameter2,
>>> + wordy_parameter3, wordy_parameter4);
>>> +
>>> +The same applies for macros.
>> 
>> For very wordy functions, or ones with silly quantities of parameters,
>> the following is also acceptable
>> 
>> void my_function_with_long_and_silly_name(
>>struct lengthy_struct_name *struct1, unsigned int womble, unsigned
>> int whatsit,
>>struct lengthy_struct_name *struct2, bool yes, bool no, bool maybe,
>>bool file_not_found, struct lengthy_struct_name *struct3, struct
>> lengthy_struct_name *struct4);
>> 
>> which you will find in a few places throughout the code, because the
>> above doesn't waste enough vertical space to fit several functions in,
>> and push all the relevant details to the RHS.
>> 
>> Per the above rules, the result would be this:
>> 
>> void my_function_with_long_and_silly_name(struct lengthy_struct_name
>> *struct1,
>>  unsigned int womble,
>>  unsigned int whatsit,
>>  struct lengthy_struct_name
>> *struct2,
>>  bool yes, bool no, bool maybe,
>>  bool file_not_found,
>>  struct lengthy_struct_name
>> *struct3,
>>  struct lengthy_struct_name
>> *struct4);
>> 
>> Of course, this is also a sign that maybe the function signature wants
>> changing anyway, but that may not be possible/sensible at the time.
>> 
>> As with everything, the coding style is a set of guidelines which are
>> applicable to 98% of cases, but there are cases where aren't
>> appropriate, and common sense is the only reasonable deciding factor.
> 
> It might be hard to automate 'common sense' cases. It seems it would
> be easier to find a solution on how to avoid such 'common sense'
> cases.
> 
> One more open point with this rule is how to format the next case where:
> len(return type string)+len(function name)+len(any of parameter) > 79
> 
> For example:
> +some_long_return_type  my_function_with_long_name(struct
> lengthy_struct_name *struct1,
> +struct lengthy_struct_name *struct2,
> +struct lengthy_struct_name *struct3);
> 
> Thanks

Ultimately we have to make some trade-offs as to what is more important:
a) automatic style checking - which means "common sense" can't be formalised 
and there will be boundary cases like the above
b) reclaiming code review bandwidth through automation or going for a labour 
intensive manual approach

I suggest we discuss in tomorrow's community call how to approach this.
I think the most important first step is to have a good view on the kind of 
boundary cases that we may face

Lars 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel