Re: [Xen-devel] [Vote] Approve hypervisor project check-in policy

[Lars Kurth]

On 27/01/2020, 14:12, "George Dunlap"  wrote:

I have drafted an explicit policy on what is (generally) required to
check a patch in.  It's been through several rounds, and v4 has been
acked [1].

I've had informal assent from all committers, but just to dot all our
i's and cross all our t's, it's probably worth having a vote of the
committers, in line with the XenProject governance policy [1].

Please respond by 10 February with your vote:
+1: for proposal
-1: against proposal
in public or private.

George: in this case - as it is not a Xen Project wide policy - the voting 
options are a bit wider

+2 : I am happy with this proposal, and I will argue for it
+1 : I am happy with this proposal, but will not argue for it
0 : I have no opinion
-1 : I am not happy with this proposal, but will not argue against it
-2 : I am not happy with this proposal, and I will argue against it

See https://xenproject.org/developers/governance/#decisions Leadership Team 
Decisions
For project wide decisions we ended up with a simpler and different scheme

Lars

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

[Xen-devel] [Announcement] CfP for Xen Project Developer Summit closes March 6th

[Lars Kurth]

Dear community members,

The CfP and Registration for the Xen Project Developer & Design Summit has been 
open for a week. This is a quick reminder that the CfP for talks closes on 
March 6th. 
Information about the CfP can be found here: 
https://events.linuxfoundation.org/xen-summit/program/cfp/

The event takes place from June 2nd through the 4th at the PRECIS Center in 
Bucharest, Romania. This means that we have to publish a schedule by end of 
March, to attract attendees which do not always come to the event. Information 
about the event can be found here: 
https://events.linuxfoundation.org/xen-summit/

The Design Sessions system is not yet open. We anticipate that it will open 
before the schedule goes live at the end of March.

Please let me know if you have questions

Best Regards
Lars


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

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

[Lars Kurth]

> On 23 Jan 2020, at 05:31, Bobby Eshleman  wrote:
> 
> On Wed, Jan 22, 2020 at 04:27:39PM +0000, Lars Kurth wrote:
>> 
>> You should also leverage the developer summit: see 
>> https://events.linuxfoundation.org/xen-summit/program/cfp/ 
>> <https://events.linuxfoundation.org/xen-summit/program/cfp/>
>> CfP closes March 6th. Design sessions can be submitted afterwards
>> 
>> Community calls may also be a good option to deal with specific issues / 
>> questions, e.g. around compile support in the CI, etc.
>> 
>> Lars
>> 
> 
> That's a really good idea.  I'll submit as I do think I can get there if 
> accepted.  Thanks for the tip on
> community calls, I did not realize Xen did those!
> 
> -Bobby

If you add your name/email address to 
https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ 
<https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/> I will CC you 
on the next invite
They are usually the 1st Thursday of each month 
Past minutes can be found at 
https://cryptpad.fr/drive/#/2/drive/edit/uZ1UjYxICjse+XlJrXrIwZXN/
Lars___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

[Lars Kurth]

> On 22 Jan 2020, at 14:57, Andrew Cooper  wrote:
> 
> On 22/01/2020 01:58, Bobby Eshleman wrote:
>> Hey everybody,
>> 
>> This is an RFC patchset for the very beginnings of adding RISC-V support
>> to Xen.  This RFC is really just to start a dialogue about supporting
>> RISC-V and align with the Xen project and community before going
>> further.  For that reason, it is very rough and very incomplete. 
>> 
>> My name is Bobby Eshleman, I'm a software engineer at
>> Star Lab / Wind River on the ARM team, mostly having worked in the Linux
>> kernel.  I've also been involved a good amount with Xen on ARM here,
>> mostly dealing with tooling, deployment, and testing.  A lot of this
>> patchset is heavily inspired by the Xen/ARM source code (particularly
>> the early setup up code).
>> 
>> Currently, this patchset really only sets up virtual memory for Xen and
>> initializes UART to enable print output.  None of RISC-V's
>> virtualization support has been implemented yet, although that is the
>> next road to start going down.  Many functions only contain dummy
>> implementations.  Many shortcuts have been taken and TODO's have been
>> left accordingly.  It is very, very rough.  Be forewarned: you are quite
>> likely to see some ungainly code here (despite my efforts to clean it up
>> before sending this patchset out).  My intent with this RFC is to align
>> early and gauge interest, as opposed to presenting a totally complete
>> patchset.
>> 
>> Because the ARM and RISC-V use cases will likely bear resemblance, the
>> RISC-V port should probably respect the design considerations that have
>> been laid out and respected by Xen on ARM for dom0less, safety
>> certification, etc...  My inclination has been to initially target or
>> prioritize dom0less (without excluding dom0full) and use the ARM
>> dom0less implementation as a model to follow.  I'd love feedback on this
>> point and on how the Xen project might envision a RISC-V implementation.
>> 
>> This patchset has _some_ code for future support for 32-bit, but
>> currently my focus is on 64-bit.
>> 
>> Again, this is a very, very rough and totally incomplete patchset.  My
>> goal here is just to gauge community interest, begin discussing what Xen
>> on RISC-V may look like, receive feedback, and see if I'm heading in the
>> right direction.
>> 
>> My big questions are:
>>  Does the Xen project have interest in RISC-V?
> 
> There is very large downstream interest in RISC-V.  So a definite yes.
> 
>>  What can be done to make the RISC-V port as upstreamable as
>>  possible?
>>  Any major pitfalls?
>> 
>> It would be great to hear all of your feedback.
> 
> Both RISC-V and Power9 are frequently requested things, and both suffer
> from the fact that, while we as a community would like them, the
> upstream intersection of "people who know Xen" and "people who know
> enough arch $X to do an initial port" is 0.
> 
> This series clearly demonstrates a change in the status quo, and I think
> a lot of people will be happy.
> 
> To get RISC-V to being fully supported, we will ultimately need to get
> hardware into the CI system, and an easy way for developers to test
> changes.  Do you have any thoughts on production RISC-V hardware
> (ideally server form factor) for the CI system, and/or dev boards which
> might be available fairly cheaply?
> 
> How much time do you have to put towards the port?  Is this something in
> your free time, or something you are doing as part of work?  Ultimately,
> we are going to need to increase the level of RISC-V knowledge in the
> community to maintain things in the future.
> 
> Other than that, very RFC series are entirely fine.  A good first step
> would be simply to get the build working, and get some kind of
> cross-compile build in CI, to make sure that we don't clobber the RISC-V
> build with common or other-arch changes.
> 
> I hope this helps.

I totally agree with what Andy says. 

You should also leverage the developer summit: see 
https://events.linuxfoundation.org/xen-summit/program/cfp/ 

CfP closes March 6th. Design sessions can be submitted afterwards

Community calls may also be a good option to deal with specific issues / 
questions, e.g. around compile support in the CI, etc.

Lars




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

Re: [Xen-devel] [PATCH v4 13/16] Regenerate autotools files

[Lars Kurth]

On 21/01/2020, 21:29, "Rich Persaud"  wrote:

On Jan 21, 2020, at 15:58, Marek Marczykowski-Górecki 
 wrote:
> 
> On Wed, Jan 15, 2020 at 04:57:29PM -0500, Rich Persaud wrote:
 On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki 
 wrote:
>>> Since we have those generated files committed to the repo (why?!),
>>> update them after changing configure.ac.
>> 
>> Is there any reason not to remove the generated configure files?  A 
developer using generated files on system B would be incorporating 
configuration assumptions from system A where the configure script was 
generated.  If we are going to ship configure scripts, do we need to document a 
"system A" reference distro/environment where all configure scripts from Xen 
will be generated?
>> 
>> 
>> Other notes:
>> 
>> 1.  Debian autoreconf works in the Xen root directory, but the default 
OpenEmbedded autoreconf uses Gnu libtoolize and fails because some Xen build 
subdirectories don't have configure.ac/.in.   
>> 
>> 2.  If OpenEmbedded autoreconf is run only in the tools directory (where 
it works and generates a new tools configure), then root configure (generated 
from older configure.ac) will silently ignore the newer tools configure and 
write config.h _without_ tools-specific config, such as the vchan QMP proxy.
>> 
>> 3. If autoreconf runs successfully in the root directory, then 
tools-specific configure is correctly generated and everything works as 
expected.
>> 
>> This silent failure could be avoided by deleting the generated configure 
scripts.  There may be other failure modes for using System A generated scripts 
on downstream build system B.
> 
> Yes, I think general good practices are:
> 1. don't keep generated autotools files in version control system
> 2. generate them into release tarballs

A potential topic for the next Xen community call:  can we delete generated 
autotools files from the Xen tree and update the release process to 
generate+bundle them with release tarballs?

I am happy to put this on the agenda, if someone reminds me closer to the time
Lars

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

Re: [Xen-devel] [Vote] For Xen Project Code of Conduct (deadline March 31st)

[Lars Kurth]

Apologies,

some of the links I added for convenience do not work

> It should be read in the following order
The correct links are

* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=code-of-conduct.md;hb=refs/heads/CoC-v5
 
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=communication-guide.md;hb=refs/heads/CoC-v5
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=code-review-guide.md;hb=refs/heads/CoC-v5
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=communication-practice.md;hb=refs/heads/CoC-v5
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=resolving-disagreement.md;hb=refs/heads/CoC-v5

Lars


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

[Xen-devel] [Vote] For Xen Project Code of Conduct (deadline March 31st)

[Lars Kurth]

Hi all,

for some time now we have been discussing the Xen Project Code of
Conduct. The most recent set of feedback has been primarily around
minor language issues (US vs UL English, etc.), which indicates to me 
that the proposal is ready to be voted on

The final version which addresses all the latest minor feedback can be
found at 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=tree;h=refs/heads/CoC-v5
 

It should be read in the following order
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=code-of-conduct.md
 
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=communication-guide.md
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=code-review-guide.md
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=communication-practice.md
 
* 
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=resolving-disagreement.md
 

In accordance with https://xenproject.org/developers/governance/, I need the
leadership teams of the three mature projects: the Hypervisor, the XAPI
project and the Windows PV Driver project to vote on this proposal.

The specific voting rules in this case are outlined in section
https://www.xenproject.org/governance.html#project-decisions 

People allowed to vote on behalf of the Hypervisor project are:
Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R
Wilk, Stefano Stabellini, Wei Liu and Paul Durrant (as Release Manager).

People allowed to vote on behalf of the XAPI project are:
Chandrika Srinivasan, Christian Lindig, Konstantina Chremmou,
Rob Hoes, Zhang Li

People allowed to vote on behalf of the Windows PV Driver Project are:
Paul Durrant, Ben Chalmers, Owen Smith

I propose to tally the votes after March 31st. You can reply via
+1: for proposal
-1: against proposal
in public or private.

Votes will be tallied by subproject – aka the Hypervisor and XAPI project by %
for the proposal - and then averaged across sub-projects that achieved the
quorum. The vote needs to achieve a 2/3 majority to pass.

Sub-project needs to achieve the following quorum of votes in favour for the
sub-project’s vote to count
Hypervisor: 3 + votes
XAPI: 2 + votes
Windows PV Drivers: 1 + votes

Regards
Lars


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

Re: [Xen-devel] [PATCH] get-maintainer.pl: Dont fall over when L: contains a display name

[Lars Kurth]

I should have added more people to this change. The issue without this fix is 
that entries such as

L: xen-devel 

break get_maintainer.pl and thus add_maintainers.pl

Lars

On 10/01/2020, 21:19, "Lars Kurth"  wrote:

From: Lars Kurth 

Prior to this change e-mail addresses of the form "display name
" would result into empty output. Also see
https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00753.html

    Signed-off-by: Lars Kurth 
---
CC: jgr...@suse.com
---
 scripts/get_maintainer.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 2e661f47d8..48e07370e8 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -1073,7 +1073,7 @@ sub add_categories {
my $ptype = $1;
my $pvalue = $2;
if ($ptype eq "L") {
-   my $list_address = $pvalue;
+   my ($list_name, $list_address) = parse_email($pvalue);  
  
my $list_additional = "";
my $list_role = get_list_role($i);
 
-- 
2.13.0



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

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

[Lars Kurth]

On 15/01/2020, 10:47, "George Dunlap"  wrote:

On 1/13/20 9:21 PM, Lars Kurth wrote:
> 
> 
> On 13/01/2020, 19:54, "George Dunlap"  wrote:
> 
> 
>     > On Dec 30, 2019, at 7:32 PM, Lars Kurth  
wrote:
> > 
> > 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
> > 
> > +### Avoid opinion: stick to the facts
> 
> In my talk on this subject I said “Avoid *inflammatory language*”.  
At some level it’s good to have strong opinions on what code should look like.  
It’s not opinions that are a problem, or even expressing opinions, but 
expressing them in a provocative or inflammatory way.
> 
> Let me look at this again: I don't feel strongly about it
> 
> I changed the title because I felt that the bulk of the 
> example is actually about sticking to the facts an opinion 
> and the inflammatory element was secondary. So it felt more
> natural to me to change the title.

Right; the point though specifically is that people's natural, and
probably healthy response to poorly-written code, or to
inconsiderately-written patch series in any way, is to use charged
language.  I wouldn't call any code "garbage", but code submitted is
sometimes actually terrible, fragile, spaghetti, inefficient, racy,
messy -- whatever bad things you can say about it -- and any
well-trained developer will have the same opinion.

[snip]

I think people should be able to pick up what we mean from the reasoning
and from the examples.

I attached a conversation log on IRC and a diff against this snippet of the 
code for a resolution

‹lars_kurth›  gwd: I just read your feedback on the CoC. I now agree with your 
argument that "Avoid opinion:  stick to the facts" is a bad heading for that 
section 
‹lars_kurth›  gwd: however I still dont like “Avoid *inflammatory language*” - 
I am wondering whether "Avoid language that triggers a negative response" would 
be better 
‹gwd›   What is it you don't like about "inflammatory"? 
‹lars_kurth›  Also, I think I need to re-write some of the bridging paragraphs 
to fit the title 
‹gwd›  (Not arguing for 'inflammatory' per se, but knowing what you don't like 
about it helps if I'm trying to find an alternative) 
‹lars_kurth›  Firstly it is now somewhat politically charged (in some 
cultures), secondly I am not sure how well it translates and how clear it is to 
non-native english speakers 
‹gwd›  Any opinions on the other words I suggested? 
‹lars_kurth›  Provocative seems ok 
* Diziet reads the thread.
‹lars_kurth›  "charged"? "loaded"? seems too generic 
‹lars_kurth›  "derogatory"? "contemptuous"? seems to be too harsh and infer too 
much bad intent
‹Diziet›  "avoid ... emotive" maybe ? [11:18:15][11:18:31]  
‹Diziet›  "avoid derogatory or emotive language" ? 
‹lars_kurth›  Diziet, gwd: I think emotive is good and we can add derogatory 
‹gwd›  Doesn't "emotive" include positive emotions? "This patch is amazing, 
thank you" is a lot better than "This patch effictively simplifies this 
codebase very well, thank you". :-) 
‹lars_kurth›  That is true 
‹lars_kurth›  The same would be true for charged and loaded 
‹Diziet›  gwd: Hrm
‹Diziet›  To be unambiguous I think only "negatively charged" will do. You 
can't have "negatively emotive" or some such. 
‹Diziet›  You could say "avoid emotive criticism" 
‹gwd›  I feel like "charged" is used more often for negative things.
‹lars_kurth›  OK. Let's stick with Inflammatory and I can replace "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." in the first paragraph with a 
sentence that clarifies that the intention is to avoid triggering negativity 
‹lars_kurth›  I am going to draft some text for this section and send it in 
response rather than doing a new version for now 
‹gwd›  +
‹Diziet›  I think `derogatory' and `emotive criticism' and `negatively charged' 
are all better than `inflammatory'. 
‹Diziet›  But `inflammatory' will do.
‹lars_kurth›  The section as it is comes across as a little clumsy (in that it 
doesn't flow well
‹lars_kurth›  As an aside: does anyone know how I can redact text in markdown? 
I guess I can just add "" for words I dont want to show 
‹Diziet›  https://stackoverfl

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

[Lars Kurth]

On 13/01/2020, 19:54, "George Dunlap"  wrote:


> On Dec 30, 2019, at 7:32 PM, Lars Kurth  wrote:
> 
    > 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
> 
> +### Avoid opinion: stick to the facts

In my talk on this subject I said “Avoid *inflammatory language*”.  At some 
level it’s good to have strong opinions on what code should look like.  It’s 
not opinions that are a problem, or even expressing opinions, but expressing 
them in a provocative or inflammatory way.

Let me look at this again: I don't feel strongly about it

I changed the title because I felt that the bulk of the 
example is actually about sticking to the facts an opinion 
and the inflammatory element was secondary. So it felt more
natural to me to change the title.

But then looking at the definition of inflammatory language,
aka  "an inflammatory question or an inflammatory statement
would be one which would somehow predispose the listeners
towards a subject in an unreasonable, prejudiced way."
It is clearly also true that the example is inflammatory.

I think I may have tripped over an area where there is no good
language match: the German translations of inflammatory
aufrührerisch & aufwieglerisch have an element of rebellion
and mischief to them (at least when I grew up).

I am wondering though, whether it is necessary to include 
a definition of an inflammatory question or an inflammatory
statement if we stick with it in the title

> 
> +> Foot binding was the custom of applying tight binding to the feet of 
young
> +> girls to modify the shape and size of their feet. ... foot binding was 
a
> +> painful practice and significantly limited the mobility of women, 
resulting
> +> in lifelong disabilities for most of its subjects. ... Binding usually
> +> started during the winter months since the feet were more likely to be 
numb,
> +> and therefore the pain would not be as extreme. …The toes on each foot
> +> were curled under, then pressed with great force downwards and squeezed
> +> into the sole of the foot until the toes broke…

In my talk I covered the last three words behind a blue square, since this 
image is pretty violent — and is gendered violence at that.  Some people joke 
about “triggering”, but there are certainly people who  have experienced 
violence, who when they come across descriptions of it unexpectedly suddenly 
have loads of unwelcome emotions to deal with; and I venture to guess that most 
people skimming through such a guide wouldn’t be expecting to come across 
something like this.

Personally I would replace the last three words with [redacted].  The point 
can be made without being so explicit.  Anyone who wants to know what happens 
can go look up the entry themselves.

OK. I can do that. 
I copied the text from the content outline on slide share and wasn't even 
looking at the slides themselves

Lars



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

[Xen-devel] [PATCH] get-maintainer.pl: Dont fall over when L: contains a display name

[Lars Kurth]

From: Lars Kurth 

Prior to this change e-mail addresses of the form "display name
" would result into empty output. Also see
https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00753.html

Signed-off-by: Lars Kurth 
---
CC: jgr...@suse.com
---
 scripts/get_maintainer.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 2e661f47d8..48e07370e8 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -1073,7 +1073,7 @@ sub add_categories {
my $ptype = $1;
my $pvalue = $2;
if ($ptype eq "L") {
-   my $list_address = $pvalue;
+   my ($list_name, $list_address) = parse_email($pvalue);  
  
my $list_additional = "";
my $list_role = get_list_role($i);
 
-- 
2.13.0


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

Re: [Xen-devel] [PATCH] Introduce CHANGELOG.md

[Lars Kurth]

> On 10 Jan 2020, at 17:54, Andrew Cooper  wrote:
> 
> On 10/01/2020 09:12, Paul Durrant wrote:
>> As agreed during the 2020-01 community call [1] this patch introduces a
>> changelog, based on the principles explained at keepachangelog.com [2].
>> A new MAINTAINERS entry is also added, with myself as (currently sole)
>> maintainer.
>> 
>> [1] See C.2 at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
>> [2] https://keepachangelog.com/en/1.0.0/
>> 
>> Signed-off-by: Paul Durrant 
>> ---
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Julien Grall 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Wei Liu 
>> Cc: Lars Kurth 
>> 
>> Should there be other maintainers apart from myself (with my RM hat on)?
>> Perhaps Lars should also be added as a designated reviewer?
> 
> Ultimately, the committers are last line of judgement on "whether this
> change should be in the changelog".  Practically, that includes "The
> Rest", but there was an objection to that on the call IIRC.

Am happy to be added

Lars

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

Re: [Xen-devel] [BUG] scripts/add_maintainers.pl adding empty Cc: lines

[Lars Kurth]

On 08/01/2020, 16:52, "Jürgen Groß"  wrote:

Just had a chat with Lars on IRC, which might be of common
interest (and Lars asked me to post it to xen-devel):

(17:00:16) juergen_gross: lars_kurth: any idea why 
./scripts/add_maintainers.pl would add a "Cc:" without a mail address to 
a patch? Happened e.g. in my series "[PATCH v2 0/9] xen: scheduler 
cleanups" (cover-letter, patches 1, 2, 7 and 9)
(17:01:58) lars_kurth: juergen_gross: oh, an actual bug! Let me look at 
the code
(17:02:19) lars_kurth: juergen_gross:  is it missing some e-mails?
(17:02:34) juergen_gross: git send-email seems to remove those empty Cc: 
lines
(17:02:53) juergen_gross: I'm not aware of a mail address missing. Let 
me double check
(17:06:56) juergen_gross: lars_kurth: hmm, shouldn't the MAINTAINERS 
entry "L:  DornerWorks Xen-Devel " result 
in a Cc:?
(17:08:17) lars_kurth: Let me have a look
(17:13:16) juergen_gross: lars_kurth: at least the related file is 
touched exactly by the affected patches (and not by any not affected patch)
(17:13:36) lars_kurth: Looking at the series the most likely cause of 
this is the L: entry - need to look at the code
(17:15:21) lars_kurth: juergen_gross: it's also an odd one because it 
changes MAINTAINERS and renames a lot of files, which may be the cause 
for the empty spaces
(17:15:52) juergen_gross: lars_kurth: in Linux MAINTAINERS all "L:" 
entries just have a mail address as first word after the "L:" (not "bla 
bla ")
(17:16:11) lars_kurth: Ah yes: let me look at that code
(17:21:29) lars_kurth: juergen_gross: I think that is in fact the issue
(17:27:16) lars_kurth: juergen_gross: I can't fix this with some 
debugging. Could you copy this conversation into a mail on xen-devel@ 
such that I remember
(17:27:43) lars_kurth: uergen_gross: with=without
(17:29:36) lars_kurth:  juergen_gross: I think what happens is that 
get_maintainer.pl and add_maintainer.pl process these lines differently, 
but add_maintainer.pl also checks against output created from 
get_maintainer.pl
(17:44:58) juergen_gross: lars_kurth: what about doing it the easy way? 
With a modifed MAINTAINERS file (using "L: xen-de...@dornerworks.com") 
everything is fine. I can send a patch in case you agree.
(17:46:41) lars_kurth: juergen_gross: let's do that first, but I still 
would like to fix the underlying issue at some point - asking for you to 
send the IRC log, as I cleared my history by mistake (when I was typing 
a reply I slipped from shift to ctrl, which did it)


For my own reference, the issue is somewhere in get_maintainer.pl, not in 
add_maintainers.pl

In a nutshell, a line such as
L: foo bar  in MAINTAINERS

Will produce an empty line when executing sth like ./scripts/get_maintainer.pl 
< ../patches/test/0001-Add-test-case.patch

In the test case I used, I use
L: xxx yyy  in MAINTAINERS
and get
Andrew Cooper 
...
Wei Liu 

xen-devel@lists.xenproject.org

When I use
L: x...@lists.xenproject.org in MAINTAINERS
I get
Andrew Cooper 
...
Wei Liu 
x...@lists.xenproject.org
xen-devel@lists.xenproject.org

Need to investigate further
Lars

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

Re: [Xen-devel] [PATCH] Introduce CHANGELOG.md

[Lars Kurth]

On 10/01/2020, 09:12, "Paul Durrant"  wrote:

As agreed during the 2020-01 community call [1] this patch introduces a
changelog, based on the principles explained at keepachangelog.com [2].
A new MAINTAINERS entry is also added, with myself as (currently sole)
maintainer.

[1] See C.2 at 
https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
[2] https://keepachangelog.com/en/1.0.0/

Signed-off-by: Paul Durrant 


Thank you Paul
Exactly what I was looking for

Reviewed-by: Lars Kurth 

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

[Xen-devel] Updating https://wiki.xenproject.org/wiki/Outreach_Program_Projects

[Lars Kurth]

Hi all,

the deadline for GSoC mentoring orgs is approaching again and I think there is 
a good chance we might get in (usually we get in every 3 years and the last 
time we got in in 2020). We do however need to get 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects into a decent state 
PRIOR to the application deadline around Feb 5th

And this year the list is potentially in a worse than in its usual state at 
least in terms of e-mail addresses that may be wrong, etc. 

To make things a little easier look out for your name below

@George: is the project below still applicable - I saw quite a lot of activity 
around this indicating that maybe the project is done or should be changed
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#golang_bindings_for_libxl
@George: another one against you
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Add_Centos_Virt_SIG_Xen_packages_test_to_the_CentOS_CI_loop

@Paul: This is against your Citrix address - would you still support this 
project from within AWS. There was also some work from postgrads as far as I 
recall
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#KDD_.28Windows_Debugger_Stub.29_enhancements
 

@Stefano, @Julien: the 5 projects below are against you - are these still valid?
@Julien: these are against your Arm address
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_Hypervisor
- 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM:_Trap_.26_sanitize_ID_registers_.28ID_PFR0.2C_ID_DFR0.2C_etc.29
- 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM.2C_dom0less:_configurable_memory_layout_for_guests
- https://wiki.xenproject.org/wiki/Outreach_Program_Projects#ARMv8.1_atomics
- 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM:_dynamic_virtual_memory_layout
- 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM:_Performance_Counters_Virtualization

@Simon, @Felipe: the 4 projects below are against you - are these still valid? 
Or have they been implemented?
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Unikraft
- 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#New_Platform_Support
- 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#FreeBSD.27s_Network_Stack_Port
- https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Go_Language_Support
- 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Enhanced_Profiling_and_Tracing_Support

@Roger: is this still valid?
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Add_more_FreeBSD_testing_to_osstest

Regards
Lars



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

Re: [Xen-devel] Community Call: Call for Agenda Items and call details for Jan 9, 16:00 - 17:00 UTC

[Lars Kurth]

On 07/01/2020, 08:23, "Durrant, Paul"  wrote:

> -Original Message-
> From: Andrew Cooper 
> Sent: 07 January 2020 00:26
    > To: Lars Kurth ; xen-devel  de...@lists.xenproject.org>
> Cc: Rian Quinn ; Daniel P. Smith
> ; Doug Goldstein ; Brian
> Woods ; Rich Persaud ;
> anastassios.na...@onapp.com; mirela.simono...@aggios.com;
> edgar.igles...@xilinx.com; Ji, John ;
> robin.randh...@arm.com; daniel.ki...@oracle.com; Amit Shah
> ; Matt Spencer ; Robert Townley
> ; Artem Mygaiev ; Varad
> Gautam ; Tamas K Lengyel
> ; Christopher Clark
> ; George Dunlap ;
> Stefano Stabellini ; lambert.oliv...@gmail.com;
> Ian Jackson ; vfac...@de.adit-jv.com; Kevin
> Pearson ; intel-...@intel.com; Jarvis
> Roach ; Juergen Gross ;
> Sergey Dyasli ; Durrant, Paul
> ; Julien Grall ; Jeff
> Kubascik ; Natarajan, Janakarajan
> ; Stewart Hildebrand
> ; Volodymyr Babchuk
> ; Woodhouse, David ; Roger
> Pau Monne 
> Subject: Re: [Xen-devel] Community Call: Call for Agenda Items and call
> details for Jan 9, 16:00 - 17:00 UTC
> 
> On 06/01/2020 19:56, Lars Kurth wrote:
> > Dear community members,
> >
> > I hope you all had a restful holiday period and a Happy New Year!
> >
> > Please send me agenda items for this Thursday's community call (we
> agreed to move it by 1 week) preferably by Wednesday!
> >
> > A draft agenda is
> at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
> > Please add agenda items to the document or reply to this e-mail
> 
> I think it would be very helpful for the community in general to know
> any specific plans each of us have for the 4.14 timeframe.
> 
> I personally am aware of a fair quantity of work from various people,
> but it is clear that the community as a whole doesn't really have an
> idea of who is working on what.
> 
> My contribution to the discussion starts with
> https://lore.kernel.org/xen-devel/941cf23c-13ed-14a1-fd25-
> 45b001d95...@citrix.com/T/#u
> but I think it would be helpful if others gave at least a brief overview
> of any plans and whether they are intending the work to hit the next
> release, or whether it is more likely to be a future release.

Agreed. I need a baseline list of items to track for 4.14. 

I added 

   C.2) 4.13 Release retrospective and 4.14 planning baseline (Lars, Paul)
   4.13: Seems to be that this time some stuff had gone wrong, in particular 
around the release comms. This is a placeholder to discuss.

   4.14: Need a baseline for 4.14 planning
   It would be helpful if EVERYONE gave a brief overview of any plans for 4.14 
and whether they are intending the work to hit the next 
   release, or whether it is more likely to be a future release.

   Andrew's contribution and larger 4.14 backlog at: 
https://lore.kernel.org/xen-devel/941cf23c-13ed-14a1-fd25-45b001d95...@citrix.com/T/#u

To the agenda
Lars


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

[Xen-devel] Community Call: Call for Agenda Items and call details for Jan 9, 16:00 - 17:00 UTC

[Lars Kurth]

Dear community members,
 
I hope you all had a restful holiday period and a Happy New Year! 

Please send me agenda items for this Thursday's community call (we agreed to 
move it by 1 week) preferably by Wednesday!

A draft agenda is at 
https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
Please add agenda items to the document or reply to this e-mail

Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
 
Best Regards
Lars

## Meeting time (please double check the times)
16:00 - 17:00 UTC
08:00 - 09:00 PST (San Francisco) - sorry for the early time slot. If this is a 
problem, let's discuss at the call
10:00 - 11:00 CST (Austin, Costa Rica)
11:00 - 12:00 EST (New York)
16:00 - 17:00 FMT (London)
17:00 - 18:00 CET (Berlin)
00:00 - 01:00+1 CST (Beijing)

Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=1&day=9&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


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

Re: [Xen-devel] [PATCH v4 7/7] Added Resolving Disagreement

[Lars Kurth]

On 06/01/2020, 07:25, "Jürgen Groß"  wrote:

>+## 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 
disagreements
>+are typically caused by different expectations related to the level of
>+perfection a patch series needs to fulfil before it can be considered 
ready to

s/fulfil/fulfill/

>+be committed.
>+
>+To explain this better, I am going to use the analogy of some building 
work that
>+has been performed at your house. Let's say that you have a new bathroom
>+installed. Before paying your builder the last instalment, you perform an

s/instalment/installment/

Hi Juergen: thank you for pointing out the remaining typos. 

I fixed these in my local tree, with the exception of the two instances above.

The two issues above come down to US vs non-US English

https://grammarist.com/spelling/fulfil-fulfill/
https://grammarist.com/spelling/installment-instalment/ 

I didn't really review the document for consistency with respect to a 
particular style of English spelling.
It does seem though that normally I use US spelling (e.g. minimize) mostly and 
of course the Contributor
Covenant has been written US spelling. 

I don't have a strong view either way and can have a go at making it consistent 
(e.g. in US stylespelling)

Lars


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

[Xen-devel] [PATCH v4 6/7] 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

Changes since v3
* Fixed typo

Changes since v2 (added in v2)
* Fix typos
* Extended "Verbose vs. terse"
* Added "Clarity over Verbosity"
* Broke "Identify the severity of an issue or disagreement" into two chapters
  - "Identify the severity and optionality of review comments" and made
clarifications
  - "Identify the severity of a disagreement"
  - Expanded "Prioritize significant flaws"
* Added "Reviewers: Take account of previous reviewer(s) comments"
* Added prefixes such as "Reviewers:" where appropriate
* Fixed lien wrapping to 80 characters
* Replaced inline links with reference links

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 | 504 ++
 1 file changed, 504 insertions(+)
 create mode 100644 communication-practice.md

diff --git a/communication-practice.md b/communication-practice.md
new file mode 100644
index 000..438b73a
--- /dev/null
+++ b/communication-practice.md
@@ -0,0 +1,504 @@
+# 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 the 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 

[Xen-devel] [PATCH v4 4/7] 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

Changes since v3
- Also changes the TODO in code-of-conduct.md which had been lost
  in v2

Changes since v2 (introduced in v2)
- Make lines break at 80 characters

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 |  4 +--
 communication-guide.md | 67 ++
 2 files changed, 69 insertions(+), 2 deletions(-)
 create mode 100644 communication-guide.md

diff --git a/code-of-conduct.md b/code-of-conduct.md
index 7c29a4f..a6080cd 100644
--- a/code-of-conduct.md
+++ b/code-of-conduct.md
@@ -14,7 +14,7 @@ personal appearance, race, religion, or sexual identity and 
orientation.
 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][guidance].
+friendly way, etc. can be found [here][guidance]].
 
 Examples of unacceptable behavior by participants include:
 
@@ -85,7 +85,7 @@ version 1.4, available at
 https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
 
 [homepage]: https://www.contributor-covenant.org
-[guidance]: TODO-INSERT-URL
+[guidance]: communication-guide.md
 
 For answers to common questions about this code of conduct, see
 https://www.contributor-covenant.org/faq
diff --git a/communication-guide.md b/communication-guide.md
new file mode 100644
index 000..153b100
--- /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 authors.
+  It should help

[Xen-devel] [PATCH v4 0/7] Code of Conduct + Extra Guides and Best Practices + VOTE

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

Closing the discussion
==
I think we are at the point where we are ready to publish our guidance.
Feedback has been minor since the last version and loose ends were primarily
to do with missing examples.

To close this, I wanted to get votes on the proposal in the usual way.
Technically, only leadership team members of mature projects which are
Hypervisor, XAPI and the Windows PV driver project can vote.

However, in this case I do believe we do want to hear voices of others.

Voting would follow the rules outlined in
https://xenproject.org/developers/governance/#project-decisions

Leadership team members should vote by replying if they are happy with the
substance of the proposal by using the usual terminology
+2 : I am happy with this proposal, and I will argue for it
+1 : I am happy with this proposal, but will not argue for it
0 : I have no opinion
-1 : I am not happy with this proposal, but will not argue against it
-2 : I am not happy with this proposal, and I will argue against it

If there are minor changes (such as typos, etc) we should fix this in due
course. If there are major objections, please highlight here but also
raise it against the specific patch and make clear what the objection is.

More notes on Changes
=
It tries to address all elements in the v2 review, which raised
a number of hard questions, which were mostly addressed in v3.

One of the main outstanding items in v3 were good examples for cover letters
and well structured large patch series which were added in v4.

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

I also reformatted the series to 80 characters and replaced
inline style links with reference style links to make it easier
to stick to a character limit.

[1] https://www.contributor-covenant.org/version/1/4/code-of-conduct.md
[2] http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=summary
[3] 
http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=shortlog;h=refs/heads/CoC-v4

Changes since v3
  * More typo and whitespace fixes

  code-review-guide.md
* Added example under *Workflow from a Reviewer's Perspective* section

Changes since v2
  * Reformatted all text to 80 characters and replaced link style

  code-review-guide.md
  * Extend introduction
  * Add "Code Review Workflow" covering
- "Workflow from a Reviewer's Perspective"
- "Workflow from an Author's Perspective"
- "Problematic Patch Reviews"

  TODO: find suitable examples on how to structure/describe good patch series

  communication-practice.md
  * Fix typos
  * Extended "Verbose vs. terse"
  * Added "Clarity over Verbosity"
  * Broke "Identify the severity of an issue or disagreement" into two chapters
- "Identify the severity and optionality of review comments" and made
  clarifications
- "Identify the severity of a disagreement"
- Expanded "Prioritize significant flaws"
  * Added "Reviewers: Take account of previous reviewer(s) comments"
  * Added prefixes such as "Reviewers:" where appropriate

  resolving-disagreement.md
  * Fix typos
  * Add section: "Issue: Multiple ways to solve a problem"

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 (7):
  Import v1.4 of Contributor Covenant CoC
  Xen Project Code of Conduct
  Reformat Xen Project CoC to fit into 80 character limit
  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 v4 5/7] 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.

Changes since v3
* Added example under *Workflow from a Reviewer's Perspective* section
* Fixed typos in text introduced in v2

Changes since v2 (introduced in v2)
* Extend introduction
* Add "Code Review Workflow" covering
  - "Workflow from a Reviewer's Perspective"
  - "Workflow from an Author's Perspective"
  - "Problematic Patch Reviews"
* Wrap to 80 characters
* Replace inline links with reference links to make
  wrapping easier

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 | 313 +++
 1 file changed, 313 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..b2c08d2
--- /dev/null
+++ b/code-review-guide.md
@@ -0,0 +1,313 @@
+# 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.
+
+Before we start, it is important to remember that the primary purpose of a
+a code review is to identify any bugs or potential bugs in the code. Most code
+reviews are relatively straight-forward and do not require re-writing the
+submitted code substantially.
+
+The document provides advice on how to structure larger patch series and
+provides  pointers on code author's and reviewer's workflows.
+
+Sometimes it happens that a submitted patch series made wrong assumptions or 
has
+a flawed design or architecture. This can be frustrating for contributors and
+code  reviewers. Note that this document does contain [a section](#problems)
+that provides  suggestions on how to minimize the impact for most stake-holders
+and also on how to avoid such situations.
+
+This document does **not cover** the following topics:
+* [Communication Best Practice][1]
+* [Resolving Disagreement][2]
+* [Patch Submission Workflow][3]
+* [Managing Patch Submission with Git][4]
+
+## 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 ef???cient 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][5] and [tools/libxl/CODING_STYLE][6]
+* 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][7]
+  folder.
+* When adding new features that have an impact on the end-user,
+  a contributor should include an update to the [SUPPORT.md][8] 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][9] or [xen/test][A]
+  Unit testing is hard for a system like

[Xen-devel] [PATCH v4 1/7] 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 v4 7/7] Added Resolving Disagreement

[Lars Kurth]

From: Lars Kurth 

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

Changes since v3
* Fixed broken http link (typo)

Changes since v2 (added in v2)
* Fix typos
* Add section: "Issue: Multiple ways to solve a problem"
* Changed line wrapping to 80 characters
* Replaced inline style links with reference style links

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 | 188 ++
 1 file changed, 188 insertions(+)
 create mode 100644 resolving-disagreement.md

diff --git a/resolving-disagreement.md b/resolving-disagreement.md
new file mode 100644
index 000..fb3b134
--- /dev/null
+++ b/resolving-disagreement.md
@@ -0,0 +1,188 @@
+# 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][1]**, 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 Disagreement][2]|
+| *A representation of Graham's hierarchy of disagreement from [Loudacris][3]
+  modified by [Rocket000][4]* |
+
+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 a patch to implement additional
+functionalities.
+
+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][5]
+
+Occasionally discussions about unimportant but easy-to-grasp issues can lead to
+prolonged and unproductive discussions. 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][6] or
+[lazy voting][7] 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 disagreements
+are typically caused by different expectations related 

[Xen-devel] [PATCH v4 3/7] Reformat Xen Project CoC to fit into 80 character limit

[Lars Kurth]

From: Lars Kurth 

No content changes

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 | 62 +-
 1 file changed, 33 insertions(+), 29 deletions(-)

diff --git a/code-of-conduct.md b/code-of-conduct.md
index ee751a7..7c29a4f 100644
--- a/code-of-conduct.md
+++ b/code-of-conduct.md
@@ -5,16 +5,16 @@
 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.
+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
 
 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.
+creating a welcoming environment, how to communicate in an effective and
+friendly way, etc. can be found [here][guidance].
 
 Examples of unacceptable behavior by participants include:
 
@@ -29,41 +29,43 @@ Examples of unacceptable behavior by participants include:
 
 ## Our Responsibilities
 
-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 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 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,
-threatening, offensive, or harmful.
+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, threatening, offensive, or harmful.
 
 ## Scope
 
-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 the project leadership.
+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 the
+project leadership.
 
 ## 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 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. 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.
+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.
 
 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

[Xen-devel] [PATCH v4 2/7] 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 
---
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-decision

Re: [Xen-devel] [PATCH v3 5/7] Add Code Review Guide

[Lars Kurth]

> On 19 Dec 2019, at 09:56, Jan Beulich  wrote:
> 
> On 18.12.2019 18:09, Lars Kurth wrote:
>> 
>> 
>> On 18/12/2019, 14:29, "Julien Grall"  wrote:
>> 
>>Hi Lars,
>> 
>>On 12/12/2019 21:14, Lars Kurth wrote:
>>> +### Workflow from an Author's Perspective
>>> +
>>> +When code authors receive feedback on their patches, they typically first 
>>> try
>>> +to clarify feedback they do not understand. For smaller patches or patch 
>>> series
>>> +it makes sense to wait until receiving feedback on the entire series before
>>> +sending out a new version addressing the changes. For larger series, it may
>>> +make sense to send out a new revision earlier.
>>> +
>>> +As a reviewer, you need some system that he;ps ensure that you address all
>> 
>>Just a small typo: I think you meant "helps" rather than "he;ps".
>> 
>>Cheers,
>> 
>> Thank you: fixed in my working copy.
>> 
>> One thing which occurred to me for reviews like these, where there is no 
>> ACK's or Reviewed-by's is that I don't actually know whether you as reviewer 
>> is otherwise happy with the remainder of the patch.
>> Normally the ACKed-by or Reviewed-by is a signal that it is
>> 
>> I am assuming it is, but I think it may be worthwhile pointing this out in 
>> the document, that unless stated otherwise, the reviewer is happy with the 
>> patch
> 
> I don't think there should ever be such an implication. Afaic there
> are patches I comment upon, but that I either don't feel qualified
> to give an ack/R-b on, or that I simply don't want to for whatever
> reason. At best, no other comment (as in the above example) may be
> taken as "I don't object".


If that is the case, would there be a reasonable convention to make this clear? 

In a nutshell, in such a review the possible interpretations are
* I reviewed, but didn't feel qualified to do the rest
* I reviewed, but did not get round to give it full attention
* I reviewed, but before I make a final decision want to look at the next 
version
...
* I reviewed and don't object the rest
* I reviewed and agreed with the rest 
The latter two are equivalent to Ack/R-b

That is quite a large range of possibilities and kind of leaves the author 
guessing what state the review is in

Regards
Lars




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

Re: [Xen-devel] [PATCH v3 5/7] Add Code Review Guide

[Lars Kurth]

On 18/12/2019, 14:29, "Julien Grall"  wrote:

Hi Lars,

On 12/12/2019 21:14, Lars Kurth wrote:
> +### Workflow from an Author's Perspective
> +
> +When code authors receive feedback on their patches, they typically 
first try
> +to clarify feedback they do not understand. For smaller patches or patch 
series
> +it makes sense to wait until receiving feedback on the entire series 
before
> +sending out a new version addressing the changes. For larger series, it 
may
> +make sense to send out a new revision earlier.
> +
> +As a reviewer, you need some system that he;ps ensure that you address 
all

Just a small typo: I think you meant "helps" rather than "he;ps".

Cheers,

Thank you: fixed in my working copy.

One thing which occurred to me for reviews like these, where there is no ACK's 
or Reviewed-by's is that I don't actually know whether you as reviewer is 
otherwise happy with the remainder of patch.
Normally the ACKed-by or Reviewed-by is a signal that it is

I am assuming it is, but I think it may be worthwhile pointing this out in the 
document, that unless stated otherwise, the reviewer is happy with the patch

Regards
Lars 

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

Re: [Xen-devel] [PATCH] tools/python: Drop test.py

[Lars Kurth]

On 18/12/2019, 13:50, "Andrew Cooper"  wrote:

This file hasn't been touched since it was introduced in 2005 (c/s 
0c6f36628)
and has a wildly obsolete shebang for Python 2.3.  Most importantly for us 
is
that it isn't Python 3 compatible.

Drop the file entirely.  Since the 2.3 days, automatic discovery of tests 
has
been included in standard functionality.  Rewrite the test rule to use
"$(PYTHON) -m unittest discover" which is equivelent.

Dropping test.py drops the only piece of ZPL-2.0 code in the tree.  Drop the
ancillary files, and adjust COPYING to match.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Lars Kurth 

This wants backporting to 4.13 as soon as practical.

Reviewed-by: Lars Kurth (lars.ku...@citrix.com) - from a licensing perspective



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

[Xen-devel] [RFC] Integrate CoC, Governance, Security Policy and other key documents into sphinx docs

[Lars Kurth]

Hi all,

now that 4.13 is out of the way I wanted to get the CoC discussion closed - see 
https://lists.xenproject.org/archives/html/xen-devel/2019-12/threads.html#00926,
 which means I need ACKs or final suggestions. The next step would be to 
publish it on the website.

However, I have also been thinking about keeping some documents in multiple 
places and defining a *master* copy somewhere in a tree. Right now, these are a 
few personal repos that I own, which seems unnecessary, given that we have the 
sphinx docs. In the interest of improving the docs, we also need more useful 
content in the docs to guide people to them.

My proposal would be to move the master sources for a number of key process 
docs to xen.git:/docs maybe under a "Working with the Xen Project community" in 
a process-guide directory. 
This would then include content from
• http://xenbits.xen.org/gitweb/?p=people/larsk/governance.git;a=summary
• http://xenbits.xen.org/gitweb/?p=people/larsk/security-process.git;a=summary
• http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=summary

and we could also consider including some of the wiki pages related to 
contribution workflow and re-direct the pages.

We would need to answer some questions, such as
a) Are we OK with these staying in markdown - I don’t mind converting
b) Are we OK with some of the documents needing project wide agreement before 
they can be changed, specifically this would cover
- governance.git
- code-of-conduct.git:code-of-conduct.md
- code-of-conduct.git:communication-guide.md

Best Regards
Lars





 

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

Re: [Xen-devel] [PATCH] 4.13.0: Update SUPPORT.md

[Lars Kurth]

> On 17 Dec 2019, at 14:18, Ian Jackson  wrote:
> 
> Signed-off-by: Ian Jackson 
> ---
> SUPPORT.md | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index f7a7a56c29..b24649ef2d 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,13 +9,13 @@ for the definitions of the support status levels etc.
> 
> # Release Support
> 
> -Xen-Version: 4.13-rc
> -Initial-Release: n/a
> -Supported-Until: TBD
> -Security-Support-Until: Unreleased - not yet security-supported
> +Xen-Version: 4.13
> +Initial-Release: 2019-12-18
> +Supported-Until: 2021-06-18
That looks good to me: 18 months

> +Security-Support-Until: 2022-12-18
That looks good to me: 36 months

Reviewed-by: Lars Kurth mailto:lars.ku...@citrix.com>>

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

[Xen-devel] [PATCH v3 7/7] Added Resolving Disagreement

[Lars Kurth]

From: Lars Kurth 

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

Changes since v2 (added in v2)
* Fix typos
* Add section: "Issue: Multiple ways to solve a problem"
* Changed line wrapping to 80 characters
* Replaced inline style links with reference style links

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 | 188 ++
 1 file changed, 188 insertions(+)
 create mode 100644 resolving-disagreement.md

diff --git a/resolving-disagreement.md b/resolving-disagreement.md
new file mode 100644
index 000..97bca7b
--- /dev/null
+++ b/resolving-disagreement.md
@@ -0,0 +1,188 @@
+# 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][1]**, 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 Disagreement][2]|
+| *A representation of Graham's hierarchy of disagreement from [Loudacris][3]
+  modified by [Rocket000][4]* |
+
+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 a patch to implement additional
+functionalities.
+
+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][5]
+
+Occasionally discussions about unimportant but easy-to-grasp issues can lead to
+prolonged and unproductive discussions. 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][6] or
+[lazy voting][7] 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 disagreements
+are typically caused by different expectations related to the level of
+perfection a patch series needs to

[Xen-devel] [PATCH v3 6/7] 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

Changes since v2 (added in v2)
* Fix typos
* Extended "Verbose vs. terse"
* Added "Clarity over Verbosity"
* Broke "Identify the severity of an issue or disagreement" into two chapters
  - "Identify the severity and optionality of review comments" and made
clarifications
  - "Identify the severity of a disagreement"
  - Expanded "Prioritize significant flaws"
* Added "Reviewers: Take account of previous reviewer(s) comments"
* Added prefixes such as "Reviewers:" where appropriate
* Fixed lien wrapping to 80 characters
* Replaced inline links with reference links

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 | 504 ++
 1 file changed, 504 insertions(+)
 create mode 100644 communication-practice.md

diff --git a/communication-practice.md b/communication-practice.md
new file mode 100644
index 000..0ae2426
--- /dev/null
+++ b/communication-practice.md
@@ -0,0 +1,504 @@
+# 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 the 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 t

[Xen-devel] [PATCH v3 1/7] 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 v3 0/7] 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 tries to address all elements in the v2 review, which raised
a number of hard questions. One of the main outstanding items
were good examples for cover letters and well structured large
patch series (see TODO in "Add Code Review Guide")

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

I also reformatted the series to 80 characters and replaced
inline syile links with reference style links to make it easier
to stick to a character limit. To just see text but not formatting changes,
have a look at [4]. This is why patch 3 "Reformat Xen Project CoC to fit
into 80 character limit" was added.

[1] https://www.contributor-covenant.org/version/1/4/code-of-conduct.md
[2] http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=summary
[3] 
http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=shortlog;h=refs/heads/CoC-v3
[4] 
http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=commitdiff;h=ee96578446eb41320b3e8a3cada441bb891ad0df;hp=2e4b36afaa73277d246d7e84037db1532a136ec7

Changes since v2
  * Reformatted all text to 80 characters and replaced link style

  code-review-guide.md
  * Extend introduction
  * Add "Code Review Workflow" covering
- "Workflow from a Reviewer's Perspective"
- "Workflow from an Author's Perspective"
- "Problematic Patch Reviews"

  TODO: find suitable examples on how to structure/describe good patch series

  communication-practice.md
  * Fix typos
  * Extended "Verbose vs. terse"
  * Added "Clarity over Verbosity"
  * Broke "Identify the severity of an issue or disagreement" into two chapters
- "Identify the severity and optionality of review comments" and made
  clarifications
- "Identify the severity of a disagreement"
- Expanded "Prioritize significant flaws"
  * Added "Reviewers: Take account of previous reviewer(s) comments"
  * Added prefixes such as "Reviewers:" where appropriate

  resolving-disagreement.md
  * Fix typos
  * Add section: "Issue: Multiple ways to solve a problem"

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 (7):
  Import v1.4 of Contributor Covenant CoC
  Xen Project Code of Conduct
  Reformat Xen Project CoC to fit into 80 character limit
  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 v3 2/7] 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

[Xen-devel] [PATCH v3 5/7] 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.

Changes since v2 (introduced in v2)
* Extend introduction
* Add "Code Review Workflow" covering
  - "Workflow from a Reviewer's Perspective"
  - "Workflow from an Author's Perspective"
  - "Problematic Patch Reviews"
* Wrap to 80 characters
* Replace inline links with reference links to make
  wrapping easier

TODO: find suitable examples on how to structure/describe good patch series

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 | 309 +++
 1 file changed, 309 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..5ffbbac
--- /dev/null
+++ b/code-review-guide.md
@@ -0,0 +1,309 @@
+# 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.
+
+Before we start, it is important to remember that the primary purpose of a
+a code review is to indentify any bugs or potential bugs in the code. Most code
+reviews are relatively straight-forward and do not require re-writing the
+submitted code substantially.
+
+The document provides advice on how to structure larger patch series and
+provides  pointers on code author's and reviewer's workflows.
+
+Sometimes it happens that a submitted patch series made wrong assumptions or 
has
+a flawed design or architecture. This can be frustrating for contributors and
+code  reviewers. Note that this document does contain [a section](#problems)
+that provides  suggestions on how to minimize the impact for most stake-holders
+and also on how to avoid such situations.
+
+This document does **not cover** the following topics:
+* [Communication Best Practice][1]
+* [Resolving Disagreement][2]
+* [Patch Submission Workflow][3]
+* [Managing Patch Submission with Git][4]
+
+## 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 ef???cient 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][5] and [tools/libxl/CODING_STYLE][6]
+* 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][7]
+  folder.
+* When adding new features that have an impact on the end-user,
+  a contributor should include an update to the [SUPPORT.md][8] 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][9] or [xen/test][A]
+  Unit testing is hard for a system like Xen and typically requires building a
+  subsyste

[Xen-devel] [PATCH v3 4/7] 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

Changes since v2 (introduced in v2)
- Make lines break at 80 characters

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..3c412d9
--- /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 v3 3/7] Reformat Xen Project CoC to fit into 80 character limit

[Lars Kurth]

From: Lars Kurth 

No content changes

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 | 56 --
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/code-of-conduct.md b/code-of-conduct.md
index 5d6d1d5..4912f47 100644
--- a/code-of-conduct.md
+++ b/code-of-conduct.md
@@ -5,16 +5,16 @@
 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.
+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
 
 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).
+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:
 
@@ -29,41 +29,43 @@ Examples of unacceptable behavior by participants include:
 
 ## Our Responsibilities
 
-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 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 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,
-threatening, offensive, or harmful.
+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, threatening, offensive, or harmful.
 
 ## Scope
 
-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 the project leadership.
+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 the
+project leadership.
 
 ## 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 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. 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.
+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.
 
 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

Re: [Xen-devel] Setting up a monthly Xen Project dinner/pub-meeting

[Lars Kurth]

And this time with the correct list. Really despairing with Outlook which keeps 
adding random old contacts to my address book and puts them in front of 
frequently used entries (sigh)

From: Lars Kurth 
Date: Wednesday, 11 December 2019 at 10:31
To: "xen-de...@lists.xensource.com" , 
"mirageos-de...@lists.xenproject.org" , 
"win-pv-de...@lists.xenproject.org" , 
"minios-de...@lists.xenproject.org" 
Subject: Setting up a monthly Xen Project dinner/pub-meeting

Hi all,

with quite a few people working on Xen Project across different companies and 
organisations these days, I was wondering whether we should set up a regular 
monthly get-together. I would like to get a sense as to

  1.  Who would be willing to turn up – need to get a sense of numbers, because 
we need to see whether it is necessary to book a table
  2.  What day would be best and what week of the month
  3.  Whether we would always choose the same venue – which I guess partly 
depends on the answer to a). If the core group attending is larger than 8 
people, we probably need to book a table, which is easier if we choose the same 
venue

If the answer to c) is NO, we should probably have a local coordinator and/or 
establish what venues we do like to go through well in advance

Feel free to voice your opinion

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

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

[Lars Kurth]

> On 9 Dec 2019, at 11:02, Lars Kurth  wrote:
> 
> 
> 
> On 06/12/2019, 09:51, "Jan Beulich"  <mailto:jbeul...@suse.com>> wrote:
> 
>On 06.12.2019 00:41, Lars Kurth wrote:
>> I propose to add the following section to code-review-guide.md
>> 
>> 
>> ## Problematic Patch Reviews
>> 
>> A typical waterfall software development process is sequential with the 
>> following 
>> steps: define requirements, analyse, design, code, test and deploy. Problems 
>> uncovered by code review or testing at such a late stage can cause costly 
>> redesign 
>> and delays. The principle of **[Shift 
>> Left](https://devopedia.org/shift-left)** is to take a 
>> task that is traditionally performed at a late stage in the process and 
>> perform that task 
>> at earlier stages. The goal is to save time by avoiding refactoring.
>> 
>> Typically, problematic patch reviews uncover issues such as wrong or missed 
>> assumptions, a problematic architecture or design, or other bugs that 
>> require 
>> significant re-implementation of a patch series to fix the issue.
>> 
>> The principle of **Shift Left** also applies in code reviews. Let's assume a 
>> series has
>> a major flaw: ideally, this flaw would be picked up in the **first or second 
>> iteration** of 
>> the code review. As significant parts of the code may have to be re-written, 
>> it does not 
>> make sense for reviewers to highlight minor issues (such as style issues) 
>> until major 
>> flaws have been addressed. By providing feedback on minor issues reviewers 
>> cause 
>> the code author and themselves extra work by asking for changes to code, 
>> which 
>> ultimately may be changed later.
>> 
>> The question then becomes, how do code reviewers identify major issues 
>> early? 
>> 
>> This is where I really need help. Are there any tips and recommendations 
>> that we could give?
>> I can clearly highlight that we have RFC series, but in practice that does 
>> not solve the problem as RFCs don’t get prioritized
>> How do reviewers normally approach a series: do you a) take a big picture 
>> view first, or b) do most of you work through a series sequentially
> 
>Afaic - depends heavily on the patch / series. I wouldn't typically
>peek ahead in a series, but it has happened. But as you say
>(elsewhere) the cover letter should put in place the "big picture".
>A series should generally be reviewable going from patch to patch,
>having the cover letter in mind.
> 
> I am wondering what others do. 
> 
> I think explaining the basic work-flow from the viewpoint of a reviewer and 
> code author maybe in a separate section, which is not tied to the problem 
> case would make sense. More input from other maintainers would be valuable. 
> My gut-feel is that most reviewers "read and review" series sequentially, 
> which has implications for the author. E.g.
> - docs/design docs should be at the beginning of a series
> - key header files or changes to them should be at the beginning of a series
> - Etc
> 
>> I then propose to change the following section in communication-practice.md
>> 
>> ### Prioritize significant flaws
>> If a patch or patch series has significant flaws, such as
>> * It is built on wrong assumptions
>> * There are issues with the architecture or the design
> 
>In such a case a full review of course doesn't make much sense. But
>this is far from the typical situation. Way more often you have some
>_part_ of a patch or series which has a bigger issue, but other
>parts are in need of no or just minor changes.
> 
> I know that this is an unusual situation. But it has happened in clusters 
> frequently in the past.
> 
> I am wondering whether we should introduce some informal convention to mark 
> _part_ of a series as problematic. A simple example of how to do this in the 
> cover letter would do
> 
>> it does not make sense to do a detailed code review. In such cases, it is 
>> best to
>> focus on the major issues first and deal with style and minor issues in a 
>> subsequent
>> review. Not all series have significant flaws, but most series have 
>> different classes of 
>> changes that are required for acceptance: covering a range of major code 
>> modifications to minor code style fixes. To avoid misunderstandings between 
>> reviewers and contributors, it is important to establish and agree whether a 
>> series or 
>> part of a series has a significant flaw and agree a course of act

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

[Lars Kurth]

On 06/12/2019, 09:51, "Jan Beulich"  wrote:

On 06.12.2019 00:41, Lars Kurth wrote:
> I propose to add the following section to code-review-guide.md
> 
> 
> ## Problematic Patch Reviews
> 
> A typical waterfall software development process is sequential with the 
following 
> steps: define requirements, analyse, design, code, test and deploy. 
Problems 
> uncovered by code review or testing at such a late stage can cause costly 
redesign 
> and delays. The principle of **[Shift 
Left](https://devopedia.org/shift-left)** is to take a 
> task that is traditionally performed at a late stage in the process and 
perform that task 
> at earlier stages. The goal is to save time by avoiding refactoring.
> 
> Typically, problematic patch reviews uncover issues such as wrong or 
missed 
> assumptions, a problematic architecture or design, or other bugs that 
require 
> significant re-implementation of a patch series to fix the issue.
> 
> The principle of **Shift Left** also applies in code reviews. Let's 
assume a series has
> a major flaw: ideally, this flaw would be picked up in the **first or 
second iteration** of 
> the code review. As significant parts of the code may have to be 
re-written, it does not 
> make sense for reviewers to highlight minor issues (such as style issues) 
until major 
> flaws have been addressed. By providing feedback on minor issues 
reviewers cause 
> the code author and themselves extra work by asking for changes to code, 
which 
> ultimately may be changed later.
> 
> The question then becomes, how do code reviewers identify major issues 
early? 
> 
> This is where I really need help. Are there any tips and recommendations 
that we could give?
> I can clearly highlight that we have RFC series, but in practice that 
does not solve the problem as RFCs don’t get prioritized
> How do reviewers normally approach a series: do you a) take a big picture 
view first, or b) do most of you work through a series sequentially

Afaic - depends heavily on the patch / series. I wouldn't typically
peek ahead in a series, but it has happened. But as you say
(elsewhere) the cover letter should put in place the "big picture".
A series should generally be reviewable going from patch to patch,
having the cover letter in mind.

I am wondering what others do. 

I think explaining the basic work-flow from the viewpoint of a reviewer and 
code author maybe in a separate section, which is not tied to the problem case 
would make sense. More input from other maintainers would be valuable. My 
gut-feel is that most reviewers "read and review" series sequentially, which 
has implications for the author. E.g.
- docs/design docs should be at the beginning of a series
- key header files or changes to them should be at the beginning of a series
- Etc
   
> I then propose to change the following section in 
communication-practice.md
> 
> ### Prioritize significant flaws
> If a patch or patch series has significant flaws, such as
> * It is built on wrong assumptions
> * There are issues with the architecture or the design

In such a case a full review of course doesn't make much sense. But
this is far from the typical situation. Way more often you have some
_part_ of a patch or series which has a bigger issue, but other
parts are in need of no or just minor changes.

I know that this is an unusual situation. But it has happened in clusters 
frequently in the past.

I am wondering whether we should introduce some informal convention to mark 
_part_ of a series as problematic. A simple example of how to do this in the 
cover letter would do

> it does not make sense to do a detailed code review. In such cases, it is 
best to
> focus on the major issues first and deal with style and minor issues in a 
subsequent
> review. Not all series have significant flaws, but most series have 
different classes of 
> changes that are required for acceptance: covering a range of major code 
> modifications to minor code style fixes. To avoid misunderstandings 
between 
> reviewers and contributors, it is important to establish and agree 
whether a series or 
> part of a series has a significant flaw and agree a course of action. 
> 
> A pragmatic approach would be to
> * Highlight problematic portions of a series in the cover letter 
> * For the patch author and reviewer(s) to agree that for problematic to 
omit style and
> minor issues in the review, until the significant flaw is addressed
> 
> This saves both the patch author and reviewer(s) time. Note that some 
background
&g

Re: [Xen-devel] [PATCH for-4.13] clang: do not enable live-patching support

[Lars Kurth]

> On 6 Dec 2019, at 14:21, Andrew Cooper  wrote:
> 
> On 03/12/2019 09:17, George Dunlap wrote:
>> 
>>> On Dec 2, 2019, at 5:01 PM, Konrad Rzeszutek Wilk  
>>> wrote:
>>> 
>>> On Mon, Dec 02, 2019 at 03:55:04PM +, Andrew Cooper wrote:
 On 02/12/2019 15:53, Konrad Rzeszutek Wilk wrote:
>>> I plan to release ack the patch in case the missing maintainer's acks
>>> are not coming in too late.
>> I think Andy's objection was that there has been zero testing of
>> livepatching on gcc.  Maybe we can find someone to do a smoke-test.
> As in integrate livepatch-build tools in osstest smoke-tests?
> Because the livepatch test cases are in osstest, unless something went 
> awry?
 The sum total of livepatch testing in OSSTest is using the hand-coded
 ELF objects from the tests/ directory.
 
 This is perhaps ok for the basic mechanism, but its not representative
 of actually building real livepatches using livepatch build tools.
>>> True. But it tests the _hypervisor_ livepatch code.
>>> 
>>> I am thinking that this discussion about "oh, but livepatch-build tools 
>>> don't work b/c"
>>> is well  sucks but should never block an release as the core
>>> livepatch functionality is OK.
>> I think a parallel is if Xen doesn’t build with a particular version of the 
>> compiler, or can’t build on a particular distro for some reason.  We should 
>> certainly *try* to make things work with other projects, but if the issue is 
>> clearly with the other project, we shouldn’t have to block to wait for that 
>> other project to get things sorted out.
> 
> This isn't a valid comparison.
> 
> livepatch-build-tools is a concrete thing, built and maintained by us
> (the Xen community), explicitly for the purpose generating livepatches
> between two versions of Xen.  It lives at
> https://xenbits.xen.org/gitweb/?p=livepatch-build-tools.git;a=summary 
>  on
> xenbits, just like xen.git.


First a couple of questions: I noticed that neither Ross to xen-devel is on 
this thread

I agree with Andy: we got away lucky so far, as there have been few changes to 
the live patch-build-tools


> It *should* be used in OSSTest, have a push gate, and block breaking
> changes either to Xen or to the tools themselves, before the breaking
> changes get accepted into master of either repo.

Although I agree with you, we should not block 4.13 for it and do some manual 
testing for this release
But we should have a plan in place for 4.14 to address this and maybe agree to 
block 4.14 if that has not happened

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

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

[Lars Kurth]

From: Lars Kurth 
Date: Thursday, 28 November 2019 at 19:39
To: Rich Persaud 
Cc: 'Jan Beulich' , "lars.ku...@xenproject.org" 
, Stefano Stabellini , 
"xen-...@lists.xenproject.org" , 
"minios-de...@lists.xenproject.org" , 
"committ...@xenproject.org" , 
"mirageos-de...@lists.xenproject.org" , 
xen-devel , "win-pv-de...@lists.xenproject.org" 

Subject: Re: [MirageOS-devel] [PATCH v2 4/6] Add Code Review Guide

 
 
From: Rich Persaud 
Date: Thursday, 28 November 2019 at 12:21
To: Lars Kurth 
Cc: 'Jan Beulich' , "lars.ku...@xenproject.org" 
, Stefano Stabellini , 
"xen-...@lists.xenproject.org" , 
"minios-de...@lists.xenproject.org" , 
"committ...@xenproject.org" , 
"mirageos-de...@lists.xenproject.org" , 
xen-devel , "win-pv-de...@lists.xenproject.org" 

Subject: Re: [MirageOS-devel] [PATCH v2 4/6] Add Code Review Guide
 
On Nov 28, 2019, at 09:05, Lars Kurth  wrote:
 
On 28/11/2019, 07:37, "Jan Beulich"  wrote:

   On 28.11.2019 14:06, Lars Kurth wrote:


I can certainly add something on the timing , along the lines of
* For complex series, consider the time it takes to do reviews (maybe with a 
guide of LOC per hour) and give reviewers enough time to
* For series with design issues or large questions, try and highlight the key 
open issues in cover letters clearly and solicit feedback from key maintainers 
who can comment on the open issue. The idea is to save both the contributor and 
the reviewers time by focussing on what needs to be resolved 
* Don’t repost a series, unless all review comments are addressed
or the reviewers asked you to do so. The problem with this is that
this is somewhat in conflict with the "let's focus on the core
issues and not get distracted by details early on in a review cycle".
In other words, this can only work, if reviewers focus on major
issues in early reviews only and do not focus on style, coding
standards, etc.

   But this doesn't make much sense either, because then full re-reviews
   need to happen anyway on later versions, to also deal with the minor
   issues. For RFC kind of series omitting style and alike feedback
   certainly makes sense, but as soon as a patch is non-RFC, it should
   be considered good to go in by the submitter.

OK, I think we have a disconnect between ideal and reality. 

I see two issues today
* Key maintainers don't always review RFC series [they end up at the bottom of 
the priority list, even though spending time on RFCs will save time elsewhere 
later]. So the effect is that then the contributor assumes there are no major 
issues and ends it as a proper series
* In practice what has happened often in the past is that design, architecture, 
assumption flaws are found in early versions of a series.
  - This usually happens because of an oversight or because there was no design 
discussion prior to the series being posted and agreed
  - Common sense would dictate that the biggest benefit for both the reviewer, 
the contributor and the community as a whole would be to try and focus on such 
flaws and leave everything aside
  - Of course there may be value in doing a detailed review of parts of such a 
series as there may be bits that are unaffected by such a flaw
  - But there will likely be parts which are not: doing a detailed review of 
such portions wastes everyone's time

So coming back to your point. Ideally, it would be nice if we had the 
capability to call out parts of a series as "problematic" and treating such 
parts differently.
 
  We may be able to reuse some "Shift Left" terminology, including citations of 
previous Xen code reviews to illustrate categories of design issues that can be 
shifted left:
  
    https://devopedia.org/shift-left
  
I like that idea. We seem to not have come to a conclusion on this specific 
topic, but maybe for now it is sufficient to call this out as a potential issue 
in the guide.
 
Before I send out a new version, it would be good to get at least Jan’s view on 
the issue. 
 
Lars

I have a draft version of  this series ready, but wanted to check how some of 
it resonates. Also, I do have open questions, where I am looking for input from 
seasoned reviewers

I propose to add the following section to code-review-guide.md


## Problematic Patch Reviews

A typical waterfall software development process is sequential with the 
following 
steps: define requirements, analyse, design, code, test and deploy. Problems 
uncovered by code review or testing at such a late stage can cause costly 
redesign 
and delays. The principle of **[Shift Left](https://devopedia.org/shift-left)** 
is to take a 
task that is traditionally performed at a late stage in the process and perform 
that task 
at earlier stages. The goal is to save time by avoiding refactoring.

Typically, problematic patch reviews un

Re: [Xen-devel] Community Call: Minutes for call on Thursday Dec 5, 16:00 - 17:00 UTC

[Lars Kurth]

Hi all,
the minutes are at 
https://cryptpad.fr/pad/#/2/pad/view/T-vK-ZiXDrnpve64l4hvP+evA5najcmoxOOVJ8TGeBs/
 and attached
There were a few items, where the connection was bad and where I am missing 
things
ACTIONS and everything important are marked in red
The next meeting is on Jan 9, not Jan 2
Regards
Lars




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

Re: [Xen-devel] Community Call: Call for Agenda Items and call details for Thursday Dec 5, 16:00 - 17:00 UTC

[Lars Kurth]

Hi all,
a quick note to say that George may start the call: however, the call-in 
details remain the same. We have a scheduled power outage this morning, which I 
was only informed about yesterday. As the power outage affects almost the 
entire pacific coast in CR, it is conceivable that I won't have a data 
connection via 4G either. In any case, this is just a quick note: most likely 
all will work as usual.
Best Regards
Lars

On 03/12/2019, 06:21, "Lars Kurth"  wrote:

Correction: the meeting is this Thursday, the 5th
Apologies for the typo
Lars


On 02/12/2019, 20:05, "Lars Kurth"  wrote:

Dear community members,
 
please send me agenda items for this Friday’s community call (sorry for 
the late notice, I was on PTO last week). A draft agenda is at 
https://cryptpad.fr/pad/#/2/pad/edit/PCtBphoXkCTiXABJ8cdL0KuZ/ 
Please add agenda items to the document or reply to this e-mail

@Juergen: I added a slot re the 4.13 release
@Doug: I saw some activity recently about the CI Loop stuff - maybe 
worth discussing, if you have time
@Ian: you mentioned that you wanted to find a way to get sysadmin help 
from someone in the community to help maintain test infra - I wanted to run 
this past this group first to see whether any names come to mind. The required 
skillset is likely to be different to that of a developer 

UPDATE: Paul Durrant will be release manager for 4.14 - congratulations

Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/view/7l3a4mhZTU4xs0GE415OXiAj0ScKl39xdQ9wm0cwASs/
 
 
Best Regards
Lars

## Meeting time (please double check the times)
16:00 - 17:00 UTC
08:00 - 09:00 PST (San Francisco) - sorry for the early time slot. If 
this is a problem, let's discuss at the call
10:00 - 11:00 CST (Austin, Costa Rica)
11:00 - 12:00 EST (New York)
16:00 - 17:00 FMT (London)
17:00 - 18:00 CET (Berlin)
00:00 - 01:00+1 CST (Beijing)

Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=12&day=5&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&#x

Re: [Xen-devel] Community Call: Call for Agenda Items and call details for Thursday Dec 5, 16:00 - 17:00 UTC

[Lars Kurth]

Correction: the meeting is this Thursday, the 5th
Apologies for the typo
Lars


On 02/12/2019, 20:05, "Lars Kurth"  wrote:

Dear community members,
 
please send me agenda items for this Friday’s community call (sorry for the 
late notice, I was on PTO last week). A draft agenda is at 
https://cryptpad.fr/pad/#/2/pad/edit/PCtBphoXkCTiXABJ8cdL0KuZ/ 
Please add agenda items to the document or reply to this e-mail

@Juergen: I added a slot re the 4.13 release
@Doug: I saw some activity recently about the CI Loop stuff - maybe worth 
discussing, if you have time
@Ian: you mentioned that you wanted to find a way to get sysadmin help from 
someone in the community to help maintain test infra - I wanted to run this 
past this group first to see whether any names come to mind. The required 
skillset is likely to be different to that of a developer 

UPDATE: Paul Durrant will be release manager for 4.14 - congratulations

Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/view/7l3a4mhZTU4xs0GE415OXiAj0ScKl39xdQ9wm0cwASs/
 
 
Best Regards
Lars

## Meeting time (please double check the times)
16:00 - 17:00 UTC
08:00 - 09:00 PST (San Francisco) - sorry for the early time slot. If this 
is a problem, let's discuss at the call
10:00 - 11:00 CST (Austin, Costa Rica)
11:00 - 12:00 EST (New York)
16:00 - 17:00 FMT (London)
17:00 - 18:00 CET (Berlin)
00:00 - 01:00+1 CST (Beijing)

Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=12&day=5&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




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

[Xen-devel] Community Call: Call for Agenda Items and call details for Dec 4, 16:00 - 17:00 UTC

[Lars Kurth]

Dear community members,
 
please send me agenda items for this Friday’s community call (sorry for the 
late notice, I was on PTO last week). A draft agenda is at 
https://cryptpad.fr/pad/#/2/pad/edit/PCtBphoXkCTiXABJ8cdL0KuZ/ 
Please add agenda items to the document or reply to this e-mail

@Juergen: I added a slot re the 4.13 release
@Doug: I saw some activity recently about the CI Loop stuff - maybe worth 
discussing, if you have time
@Ian: you mentioned that you wanted to find a way to get sysadmin help from 
someone in the community to help maintain test infra - I wanted to run this 
past this group first to see whether any names come to mind. The required 
skillset is likely to be different to that of a developer 

UPDATE: Paul Durrant will be release manager for 4.14 - congratulations

Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/view/7l3a4mhZTU4xs0GE415OXiAj0ScKl39xdQ9wm0cwASs/
 
 
Best Regards
Lars

## Meeting time (please double check the times)
16:00 - 17:00 UTC
08:00 - 09:00 PST (San Francisco) - sorry for the early time slot. If this is a 
problem, let's discuss at the call
10:00 - 11:00 CST (Austin, Costa Rica)
11:00 - 12:00 EST (New York)
16:00 - 17:00 FMT (London)
17:00 - 18:00 CET (Berlin)
00:00 - 01:00+1 CST (Beijing)

Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=12&day=4&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


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

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

[Lars Kurth]

On 28/11/2019, 12:50, "Stefano Stabellini"  wrote:

On Thu, 28 Nov 2019, Jan Beulich wrote:
> On 28.11.2019 01:56, Stefano Stabellini wrote:
> > On Thu, 26 Sep 2019, Lars Kurth wrote:

> > I think a good recommendation would be for the contributor to try to
> > follow the maintainers requests, even if they could be considered
> > "style", trusting their experience on the matter. And a good
> > recommendation for the maintainer would be to try to let the contributor
> > have freedom of implementation choice on things that don't make a
> > significant difference.
> 
> I think we try to, but I also think we suffer from too little
> clear documentation on e.g. style aspects. Attempts on my part
> to address this have mostly (not entirely) lead no-where (lack of
> feedback on proposed patches to ./CODING_STYLE). So for the time
> being there are (many) aspects where we have de-facto expectations
> that aren't written down anywhere, with the result of (in a subset
> of cases) disagreement on what the perceived de-facto standard
> actually is.

I recognize that it could be challenging finding a consensus to update
CODING_STYLE but it might be worth doing to reduce frictions with both
contributors and other reviewers.

But to be clear, I was also referring to things that might be actually
hard to add to CODING_STYLE, such as macro vs. static inlines, when to
split a single function into multiple smaller functions, etc.

I think this is definitely something we ought to do. I am volunteering to
pick this up, but changing/clarifying the CODING_STYLE needs to be 
considered in conjunction with checking tools

I have parked this for now, as
a) I did not want to disrupt 4.13 
b) and until recently I also didn’t fully understand what kind of coding
standards would help with safety certification

And of course, having a bot do the checking would remove the friction
entirely. 

Lars


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

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

[Lars Kurth]

On 28/11/2019, 12:12, "Rich Persaud"  wrote:

On Nov 28, 2019, at 05:12, Jan Beulich  wrote:
> 
> On 28.11.2019 01:54, Stefano Stabellini wrote:
>>> On Thu, 26 Sep 2019, Lars Kurth wrote:
>>> 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.
>> 
>> I think the document is missing a couple of things:
>> 
>> - a simple one line statement that possibly the most important thing in
>>  a code review is to indentify any bugs in the code
>> 
>> - an explanation that requests for major changes to the series should be
>>  made early on (i.e. let's not change the architecture of a feature at
>>  v9 if possible) I also made this comment in reply to patch #5. I'll
>>  let you decide where is the best place for it.
> 
> This needs balancing. People crucial to the evaluation of a new
> feature and its implementation simply may not have the time to
> reply prior to v9. We've had situations where people posted new
> revisions every other day, sometimes even more than one per day.
> 
> As indicated in several other contexts before - imo people not
> helping to shoulder the review load should also not have the
> expectation that their (large) contributions will be looked at
> in due course. 

To make this actionable, we could have:

- reviewer demand index:  automated index of open patches still in need of 
review, sorted by decreasing age

- review flow control:  each new patch submission cites one recent review 
by the patch submitter, for a patch of comparable size

- reviewer supply growth:  a bootstrapping guide for new reviewers and 
submitters, with patterns, anti-patterns, and examples to be emulated

That is a great idea. However, I would not want to hold up the publication of 
these documents on these suggestions. Some of them would require implementing 
tools. I was hoping there would be more progress on lore and others 
tooling/workflow related stuff by now. So I think for now, I think it is 
sufficient to set expectations better.

Regards
Lars

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

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

[Lars Kurth]

On 27/11/2019, 18:56, "Stefano Stabellini"  wrote:

On Thu, 26 Sep 2019, Lars Kurth wrote:
    > 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)
 |
 ^ Disagreement

This is a NIT but in a few places in this series you go over the
original line length.

True: typically for URLs. Primarily because I don't know whether they are 
rendered correctly when split

> +| *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.
   ^ a patch  ^ 
functionalities 


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

I think we should mention somewhere here that it is recommended for
reviewers to be explicit about whether a request is optional or whether
it is a requirement.

For instance: "I think it would be good if X 

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

[Lars Kurth]

From: Rich Persaud 
Date: Thursday, 28 November 2019 at 12:21
To: Lars Kurth 
Cc: 'Jan Beulich' , "lars.ku...@xenproject.org" 
, Stefano Stabellini , 
"xen-...@lists.xenproject.org" , 
"minios-de...@lists.xenproject.org" , 
"committ...@xenproject.org" , 
"mirageos-de...@lists.xenproject.org" , 
xen-devel , "win-pv-de...@lists.xenproject.org" 

Subject: Re: [MirageOS-devel] [PATCH v2 4/6] Add Code Review Guide

On Nov 28, 2019, at 09:05, Lars Kurth  wrote:

On 28/11/2019, 07:37, "Jan Beulich"  wrote:

   On 28.11.2019 14:06, Lars Kurth wrote:

I can certainly add something on the timing , along the lines of
* For complex series, consider the time it takes to do reviews (maybe with a 
guide of LOC per hour) and give reviewers enough time to
* For series with design issues or large questions, try and highlight the key 
open issues in cover letters clearly and solicit feedback from key maintainers 
who can comment on the open issue. The idea is to save both the contributor and 
the reviewers time by focussing on what needs to be resolved
* Don’t repost a series, unless all review comments are addressed
or the reviewers asked you to do so. The problem with this is that
this is somewhat in conflict with the "let's focus on the core
issues and not get distracted by details early on in a review cycle".
In other words, this can only work, if reviewers focus on major
issues in early reviews only and do not focus on style, coding
standards, etc.

   But this doesn't make much sense either, because then full re-reviews
   need to happen anyway on later versions, to also deal with the minor
   issues. For RFC kind of series omitting style and alike feedback
   certainly makes sense, but as soon as a patch is non-RFC, it should
   be considered good to go in by the submitter.

OK, I think we have a disconnect between ideal and reality.

I see two issues today
* Key maintainers don't always review RFC series [they end up at the bottom of 
the priority list, even though spending time on RFCs will save time elsewhere 
later]. So the effect is that then the contributor assumes there are no major 
issues and ends it as a proper series
* In practice what has happened often in the past is that design, architecture, 
assumption flaws are found in early versions of a series.
  - This usually happens because of an oversight or because there was no design 
discussion prior to the series being posted and agreed
  - Common sense would dictate that the biggest benefit for both the reviewer, 
the contributor and the community as a whole would be to try and focus on such 
flaws and leave everything aside
  - Of course there may be value in doing a detailed review of parts of such a 
series as there may be bits that are unaffected by such a flaw
  - But there will likely be parts which are not: doing a detailed review of 
such portions wastes everyone's time

So coming back to your point. Ideally, it would be nice if we had the 
capability to call out parts of a series as "problematic" and treating such 
parts differently.

  We may be able to reuse some "Shift Left" terminology, including citations of 
previous Xen code reviews to illustrate categories of design issues that can be 
shifted left:

https://devopedia.org/shift-left

I like that idea. We seem to not have come to a conclusion on this specific 
topic, but maybe for now it is sufficient to call this out as a potential issue 
in the guide.

Before I send out a new version, it would be good to get at least Jan’s view on 
the issue.

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/11/2019, 19:06, "Stefano Stabellini"  wrote:

On Fri, 27 Sep 2019, 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.
> 
> 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.

Reading the document, I think Jan has a point that it gives the
impression that following the suggestions would take significant
efforts, while actually I don't think Lars meant it that way at all, and
I don't think it should be the case either.

Yes. Ultimately the effect of a better communication should overall be a 
net-positive in terms of effort. 

Maybe we should highlight and encourage "clarity" instead of "verbosity"
of the communication, and encourage "expressing appreciation" to
newcomers, not necessarily to seasoned contributors.

Good idea

The ultimate goal of this document is actually to *reduce* our overall
efforts by making our communication more efficient, not to increase
efforts. Maybe it is worth saying this too.

It is worth saying this. 

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/11/2019, 18:57, "Stefano Stabellini"  wrote:

On Thu, 26 Sep 2019, Lars Kurth wrote:
    > 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
 ^ the top


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

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

[Lars Kurth]

On 28/11/2019, 07:37, "Jan Beulich"  wrote:

On 28.11.2019 14:06, Lars Kurth wrote:
> I can certainly add something on the timing , along the lines of
> * For complex series, consider the time it takes to do reviews (maybe 
with a guide of LOC per hour) and give reviewers enough time to
> * For series with design issues or large questions, try and highlight the 
key open issues in cover letters clearly and solicit feedback from key 
maintainers who can comment on the open issue. The idea is to save both the 
contributor and the reviewers time by focussing on what needs to be resolved 
> * Don’t repost a series, unless all review comments are addressed
> or the reviewers asked you to do so. The problem with this is that
> this is somewhat in conflict with the "let's focus on the core
> issues and not get distracted by details early on in a review cycle".
> In other words, this can only work, if reviewers focus on major
> issues in early reviews only and do not focus on style, coding
> standards, etc.

But this doesn't make much sense either, because then full re-reviews
need to happen anyway on later versions, to also deal with the minor
issues. For RFC kind of series omitting style and alike feedback
certainly makes sense, but as soon as a patch is non-RFC, it should
be considered good to go in by the submitter.

OK, I think we have a disconnect between ideal and reality. 

I see two issues today
* Key maintainers don't always review RFC series [they end up at the bottom of 
the priority list, even though spending time on RFCs will save time elsewhere 
later]. So the effect is that then the contributor assumes there are no major 
issues and ends it as a proper series
* In practice what has happened often in the past is that design, architecture, 
assumption flaws are found in early versions of a series.
   - This usually happens because of an oversight or because there was no 
design discussion prior to the series being posted and agreed
   - Common sense would dictate that the biggest benefit for both the reviewer, 
the contributor and the community as a whole would be to try and focus on such 
flaws and leave everything aside
   - Of course there may be value in doing a detailed reviews of such a series 
as there may be bits that are unaffected by such a flaw
   - But there will likely be parts which are not: doing a detailed review of 
such portions wastes everyone's time

So coming back to your point. Ideally, it would be nice if we had the 
capability to call out parts of a series as "problematic" and treating such 
parts differently

Lars

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

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

[Lars Kurth]

On 28/11/2019, 04:09, "Jan Beulich"  wrote:

On 28.11.2019 01:54, Stefano Stabellini wrote:
> On Thu, 26 Sep 2019, Lars Kurth wrote:
>> 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.
> 
> I think the document is missing a couple of things:
> 
> - a simple one line statement that possibly the most important thing in
>   a code review is to indentify any bugs in the code
> 
> - an explanation that requests for major changes to the series should be
>   made early on (i.e. let's not change the architecture of a feature at
>   v9 if possible) I also made this comment in reply to patch #5. I'll
>   let you decide where is the best place for it.

This needs balancing. People crucial to the evaluation of a new
feature and its implementation simply may not have the time to
reply prior to v9. We've had situations where people posted new
revisions every other day, sometimes even more than one per day.

I can certainly add something on the timing , along the lines of
* For complex series, consider the time it takes to do reviews (maybe with a 
guide of LOC per hour) and give reviewers enough time to
* For series with design issues or large questions, try and highlight the key 
open issues in cover letters clearly and solicit feedback from key maintainers 
who can comment on the open issue. The idea is to save both the contributor and 
the reviewers time by focussing on what needs to be resolved 
* Don’t repost a series, unless all review comments are addressed or the 
reviewers asked you to do so. The problem with this is that this is somewhat in 
conflict with the "let's focus on the core issues and not get distracted by 
details early on in a review cycle". In other words, this can only work, if 
reviewers focus on major issues in early reviews only and do not focus on 
style, coding standards, etc. As soon as a reviewer comes back with detailed 
feedback, the contributor will feel obliged to fix these. This creates a 
motivation to want to please the reviewer send out new versions of series 
fixing cosmetic issues without addressing the substantial issues, leading to 
what Jan describes. I am looking for opinions here.  

As indicated in several other contexts before - imo people not
helping to shoulder the review load should also not have the
expectation that their (large) contributions will be looked at
in due course. 

I can add something to this effect.  

Lars


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

Re: [Xen-devel] getting 4.11.3 ready

[Lars Kurth]

On 29/10/2019, 12:41, "Stefano Stabellini"  wrote:

On Tue, 29 Oct 2019, Julien Grall wrote:
> On 28/10/2019 21:43, Stefano Stabellini wrote:
> > On Mon, 28 Oct 2019, Julien Grall wrote:
> >> Hi,
> >>
> >> On 25/10/2019 11:31, Jan Beulich wrote:
> >>> All,
> >>>
> >>> the 4.11.3 stable release is due. I intend to wait for the XSA fixes
> >>> going public on the 31st, but not (much) longer. Please point out
> >>> backporting candidates that you find missing from the respective
> >>> stable trees. I have three ones queued which haven't passed the push
> >>> gate to the master branch yet:
> >>>
> >>> 9257c218e5x86/vvmx: Fix the use of RDTSCP when it is intercepted 
at L0
> >>> 7eee9c16d6x86/tsc: update vcpu time info on guest TSC adjustments
> >>> 9633929824x86: fix off-by-one in is_xen_fixed_mfn()
> >>
> >> We don't seem to have backported patches for quite a while on Arm. 
Some of my
> >> patches have been marked as to be backported from the beginning [1]. I 
am
> >> specifically thinking to:
> >>
> >> e04818b46d xen/arm: traps: Avoid using BUG_ON() to check guest state in
> >> advance_pc()
> 
> Urgh, I gave the correct title but the wrong commit sha1. It should be 
> 
> 72615f2e6b98e861c08abb1d2b194126013d54fe
> 
> > 
> > I have e04818b46d, plus the following marked for backport:
> > 
> > e98edccb944a80db782e551f3090628e66c7fb52 xen/arm: SCTLR_EL1 is a 64-bit 
register on Arm64
> 
> There are more than that to backport:
> 
> 30f5047b2c4e577436b505ba7627f34c3be02014xen/arm: gic: Make sure the 
number of interrupt lines is valid before using it  [4.11]
> 8aa276235b93eeb4f81095c638970900e19b31e5xen/arm: irq: End cleanly 
spurious interrupt[4.11]
> b4df73de493954c44f240f78779c9bd3782e1572xen/arm: gic-v2: deactivate 
interrupts during initialization[4.11]
> 0322e0db5b29a0d1ce4b452885e34023e3a4b00earm: gic-v3: deactivate 
interrupts during initialization[4.11]
> 
> 5ba1c5d0641cf63086b3058e547fcd28c3c4a011xen/arm: memaccess: 
Initialize correctly *access in __p2m_get_mem_access[4.12]
> 07e44b3d1be32fa2165c2367ae3ef9c6c8b39e1exen/arm: Implement workaround 
for Cortex A-57 and Cortex A72 AT speculate   [4.12]
> 
> 08e2059facd78d5ffaf206ba06ac2017c4adeed4xen/arm: setup: Calculate 
correctly the size of Xen [4.11+]
> 8dba9a81e7c62b8a7dbe023fffecd2e16cc20486xen/arm: Don't use _end in 
is_xen_fixed_mfn()   [4.11+]
> 671878779741b38c5f2363adceef8de2ce0b3945xen/arm: p2m: Free the p2m 
entry after flushing the IOMMU TLBs  [4.11+]
> 7f4217cc60574866cb90d67d9750228c6b86c91exen/arm: vsmc: The function 
identifier is always 32-bit [4.11+]
> 612d476e74a314be514ee6a9744eea8db09d32e5xen/arm64: Correctly compute 
the virtual address in maddr_to_virt() [4.11+]
> f51027be0688540aaab61513b06a8693a37e4c00xen/arm: fix nr_pdxs 
calculation[4.11+]
> a189ef027dbb7a3c0dfe566137f05c06d6685fb9xen/arm: mm: Flush the TLBs 
even if a mapping failed in create_xen_entries  [4.11+]

They all make sense, I did the backports, building each commit
individually.

Jan, AFAICT this is not yet ready to run the XSA checking tools.
Let me know when you think I should run them
Lars

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

Re: [Xen-devel] getting 4.12.2 ready

[Lars Kurth]

On 25/11/2019, 09:10, "Jan Beulich"  wrote:

All,

the 4.12.2 stable release is due in about 2 weeks time. Please point
out backporting candidates that you find missing from the respective
stable trees.

Jan


Hi all: 

I ran the XSA scripts and all is fine. BreaThe tool does not always understand 
the
xsa303/*.patch xen-unstable .. Xen 4.9
notation in xsa.git, which is not well defined. But it's probably not worth 
trying to fix this, as a manual check takes less than a minute

Tool output is below

XSA 296 : Some patches not applied => check
Applied 

XSA 297 : No patch found => check
Was applied in Xen 4.12.1

XSA 298 : All patches found (no need to check)
XSA 299 : All patches found (no need to check)

XSA 300 : No patch found => check
Linux only

XSA 301 : All patches found (no need to check)

XSA 302 : Some patches not applied => check
Applied

XSA 303 : Some patches not applied => check
Applied

XSA 304 : All patches found (no need to check)
XSA 305 : All patches found (no need to check)

Regards
Lars

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

Re: [Xen-devel] arm/vtimer: Physical timer emulation and the physical counter

[Lars Kurth]

Adding,
Artem as this is potentially of interest to the FuSa group?
Lars 

> On 14 Nov 2019, at 13:33, Jeff Kubascik  wrote:
> 
> Hello,
> 
> I'm working on a port of a RTOS (RTEMS) to Xen on ARM, and came across an
> interesting finding in how Xen emulates the physical timer on ARM.
> 
> In testing different configurations of the port, I have the RTOS configured to
> use the ARM generic physical timer. The driver operates the physical timer in
> the "CompareView" mode, where the timer condition is met when the physical
> counter reaches the programmed CompareValue.
> 
> The driver initializes the physical timer by first reading the physical 
> counter
> register CNTPCT, adding the systick interval, and then writing the result to 
> the
> CompareValue register CNTP_CVAL. This appears to be valid behavior based on my
> understanding of the ARMV8 Architecture Reference Manual, since the physical
> timer "offset" is specified to be zero.
> 
> Xen will trap accesses to the physical timer registers - CNTP_CTL, CNTP_CVAL,
> and CNTP_TVAL, which happens in xen/arch/arm/vtimer.c. Xen will add or remove 
> an
> offset phys_timer_base.offset when reading or writing to the 
> CNTP_CVAL/CNTP_TVAL
> registers. This offset is determined when the vtimer is initialized on guest
> creation.
> 
> However, Xen does not trap access to the physical counter register CNTPCT. 
> This
> means the guest has direct access to the register. It also means the offset is
> not applied here. I believe this is a problem, because the physical timer is 
> no
> longer consistent with the physical counter from the guest's perspective - 
> there
> is a non-zero, unknown offset between the two.
> 
> This was a problem for the RTOS, since it was reading the physical counter
> register (Xen does not apply an offset), adding some interval, and then 
> setting
> the CompareValue register (Xen applies the offset), resulting in a long delay
> before the timer expires.
> 
> I was able to fix this by adding code in Xen to trap access to CNTPCT and
> applying the offset - I can submit the patch if there is interest. However, I
> was curious if there was an reason for not trapping/ emulating access to the
> physical counter register and applying the offset?
> 
> Sincerely,
> Jeff Kubascik
> 
> ___
> 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] Call for new Release Manager for Xen 4.14+

[Lars Kurth]

On 15/11/2019, 05:26, "Durrant, Paul"  wrote:

> -Original Message-
    > From: Lars Kurth 
> Sent: 07 November 2019 22:30
> To: xen-devel ; Juergen Gross
> 
> Cc: committ...@xenproject.org; Durrant, Paul ; Brian
> Woods 
> Subject: Call for new Release Manager for Xen 4.14+
> 
> Dear Community Members,
> 
> Juergen will be stepping down as Release Manager after Xen 4.13 has been
> delivered, following the 4.11 and 4.12 release. Release managers prior to
> Juergen were Julien Grall, Konrad Wilk, Wei Liu and George Dunlap. We are
> looking for active community members to follow in previous release
> managers footsteps. I also wanted to thank Juergen for performing the
> role.
> 
> We have discussed with a number of people, however Wei made the very valid
> point that we should make an announcement about the role on the list.  In
> terms of effort, the effort required prior to the release is relatively
> low (1-2 days a month), however in the last two months of the release goes
> up to 1-2 days per week. Typically release managers manage 2-3 releases.
> 
> What is involved in the role is described here:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/process/xen-
> release-
> management.pandoc;h=d6abc90a0248b769161bce79e8dc6904c654904a;hb=HEAD
> 
> If you are a community member that feels the release manager role would be
> a good match for you, please contact me: also feel free to ask me or
> previous release managers any questions

[Replying publicly as requested by Lars]

I would be happy to do the job, so you can consider me a candidate.

Thank you for stepping up Paul. 
As no-one else has done so, I suggest we can vote: a few committers are on PTO 
and then there is Thanksgiving.
So, we should allow for 2 weeks

If no-one objects, say by Monday, can I get one of you to reply to this thread 
and change the subject to something like: "[Vote] for Paul Durrant as Release 
Manager for Xen 4.14+"

Regards
Lars

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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Lars Kurth]

On 12/11/2019, 11:10, "Stefano Stabellini"  wrote:

On Tue, 12 Nov 2019, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [Xen-devel] [PATCH] Introduce a description 
of a new optional tag for Backports"):
> > Should we describe the Fixes: tag as well? These would have a similar
> > purpose to the backport tag, I mean it could help figure out which
> > commit to backport to which tree.
> 
> Good point.

Yes, good idea.


Lars, I think we are already in agreement.

You can find the description of "Fixes" here in Linux
Documentation/process/submitting-patches.rst.

It would be good to get Jan's ACK at least
Lars


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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Lars Kurth]

On 11/11/2019, 11:03, "Stefano Stabellini"  wrote:

On Mon, 11 Nov 2019, Lars Kurth wrote:
> On 11/11/2019, 08:12, "George Dunlap"  wrote:
> 
> On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini 
> > CC: jbeul...@suse.com
> > CC: george.dun...@citrix.com
> > CC: jul...@xen.org
> > CC: lars.ku...@citrix.com
> > CC: andrew.coop...@citrix.com
> > CC: ian.jack...@eu.citrix.com
> > CC: konrad.w...@oracle.com
> > CC: w...@xen.org
> > ---
> >  docs/process/backport-tag.pandoc | 23 +++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 docs/process/backport-tag.pandoc
> > 
> > diff --git a/docs/process/backport-tag.pandoc 
b/docs/process/backport-tag.pandoc
> > new file mode 100644
> > index 00..e570efdcc8
> > --- /dev/null
> > +++ b/docs/process/backport-tag.pandoc
> > @@ -0,0 +1,23 @@
> > +Backport Tag
> > +
> > +
> > +A backport tag is an optional tag in the commit message to request 
a
> > +given commit to be backported to the stable trees:
> > +
> > +Backport: all
> > +
> > +It marks a commit for being a candidate for backports to all 
relevant
> > +trees.
> > +
> > +Backport: 4.9+
> > +
> > +It marks a commit for being a candidate for backports to all stable
> > +trees from 4.9 onward.
> > +
> > +Maintainers request the Backport tag to be added on commit.
> > +Contributors are also welcome to mark their patches with the 
Backport
> > +tag when they deem appropriate. Maintainers will request for it to 
be
> > +removed when that is not the case.
> > +
> > +Please note that the Backport tag is a **request** for backport, 
which
> > +will still need to be evaluated by the stable tree maintainers.
> 
> The text and the idea both look good to me.

Thank you!


> But it seems kind of balkanized to put it in its own file.  Would it 
be
> better to try to make a slightly more general bit of content?  Either
> about the backport process, or about tags in general?

Yeah, it was never meant to stay in its own separate file. I thought it
would get merged into a bigger file about the whole process when it gets
submitted.


> It should be in 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
> What is currently missing is
> - Release-Acked-by
> - The new proposed tag 
> 
> But maybe we should have a master document in tree, which defines the 
tags in use
> And then I can refer to it from 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
 

For now, would you like me to add the text to the wiki at

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
 ?
Or would you rather do it?

No: I can do it. Just ping me when we are in agreement about the proposal
Lars

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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Lars Kurth]

On 11/11/2019, 08:12, "George Dunlap"  wrote:

On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini 
> CC: jbeul...@suse.com
> CC: george.dun...@citrix.com
> CC: jul...@xen.org
> CC: lars.ku...@citrix.com
> CC: andrew.coop...@citrix.com
> CC: ian.jack...@eu.citrix.com
> CC: konrad.w...@oracle.com
> CC: w...@xen.org
> ---
>  docs/process/backport-tag.pandoc | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 docs/process/backport-tag.pandoc
> 
> diff --git a/docs/process/backport-tag.pandoc 
b/docs/process/backport-tag.pandoc
> new file mode 100644
> index 00..e570efdcc8
> --- /dev/null
> +++ b/docs/process/backport-tag.pandoc
> @@ -0,0 +1,23 @@
> +Backport Tag
> +
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:
> +
> +Backport: all
> +
> +It marks a commit for being a candidate for backports to all relevant
> +trees.
> +
> +Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to all stable
> +trees from 4.9 onward.
> +
> +Maintainers request the Backport tag to be added on commit.
> +Contributors are also welcome to mark their patches with the Backport
> +tag when they deem appropriate. Maintainers will request for it to be
> +removed when that is not the case.
> +
> +Please note that the Backport tag is a **request** for backport, which
> +will still need to be evaluated by the stable tree maintainers.

The text and the idea both look good to me.

But it seems kind of balkanized to put it in its own file.  Would it be
better to try to make a slightly more general bit of content?  Either
about the backport process, or about tags in general?

It should be in 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
What is currently missing is
- Release-Acked-by
- The new proposed tag 

But maybe we should have a master document in tree, which defines the tags in 
use
And then I can refer to it from 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
 

Regards
Lars


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

Re: [Xen-devel] Community Call Minutes: Nov 7

[Lars Kurth]

Hi all,
minutes are attached or at 
https://cryptpad.fr/pad/#/2/pad/view/7l3a4mhZTU4xs0GE415OXiAj0ScKl39xdQ9wm0cwASs/embed/present/
Regards
Lars

On 07/11/2019, 07:24, "Lars Kurth"  wrote:

Hi all,

quick reminder re agenda items. What I have so far is at 
https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/ 

C.1) Any more 4.13 coordination (Juergen)
C.2) Volunteers/suggestions for Release Managers for 4.13 (Lars / Juergen)
C.3) 4.13 Release Notes / Blog Post / Feature List - needs review (Lars)
See 
https://docs.google.com/document/d/1EpigvxDzeoc1dOMFwQ9itDXY4vY7nvxPiLGcNQQmX28/edit?usp=sharing

AOB
1) Travel and discussions
Rich Persaud, Christopher Clark & Daniel Smith will be in Cambridge Dec 10 
pm & 11 am 
Discussions are planned around a number of topics such as state of XSM, 
DomB proposal as a secure means to start an L0/L1 configuration, KCONFIG for L0 
version of Xen, etc.
Citrix will host, but others are welcome to join (please contact Lars for 
logistics)

Feel free to request additional items

Regards
Lars

On 04/11/2019, 05:37, "Lars Kurth"  wrote:

Dear community members,
 
please send me agenda items for next week’s community call. A draft 
agenda is at https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/
Please add agenda items to the document or reply to this e-mail
Note that I am on PTO today and tomorrow
 
Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/edit/4FGEw81flPUiivkjkuvQJ-CK/
 
Best Regards
Lars

## Meeting time (please double check the times
15:00 - 16:00 UTC
07:00 - 08:00 PST (San Francisco) - sorry for the early time slot. If 
this is a problem, let's discuss at the call
10:00 - 11:00 EST (New York)
15:00 - 16:00 FMT (London)
16:00 - 17:00 CET (Berlin)
23:00 - 22:00 CST (Beijing)
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018&month=11&day=7&hour=15&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








2019-11 Community Call.pdf
Descripti

[Xen-devel] Call for new Release Manager for Xen 4.14+

[Lars Kurth]

Dear Community Members, 

Juergen will be stepping down as Release Manager after Xen 4.13 has been 
delivered, following the 4.11 and 4.12 release. Release managers prior to 
Juergen were Julien Grall, Konrad Wilk, Wei Liu and George Dunlap. We are 
looking for active community members to follow in previous release managers 
footsteps. I also wanted to thank Juergen for performing the role. 

We have discussed with a number of people, however Wei made the very valid 
point that we should make an announcement about the role on the list.  In terms 
of effort, the effort required prior to the release is relatively low (1-2 days 
a month), however in the last two months of the release goes up to 1-2 days per 
week. Typically release managers manage 2-3 releases.

What is involved in the role is described here: 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/process/xen-release-management.pandoc;h=d6abc90a0248b769161bce79e8dc6904c654904a;hb=HEAD

If you are a community member that feels the release manager role would be a 
good match for you, please contact me: also feel free to ask me or previous 
release managers any questions

Best Regards
Lars

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

Hi all,

I have received informal advice

On 21/10/2019, 06:54, "Artem Mygaiev"  wrote:

>  Before we ask Xen FuSA contributors to invest in documentation to
> be presented as legally-valid evidence for certification, we should
> ask a certified lawyer for their formal opinion on the validity of:
> 
>   (a) applying a source code license (BSD) to documentation
> 
> There are also BSD documentation license variants which may be worth
> looking at

There is no LEGAL issue with using a source code license for documentation
Typically, community issues arise when the license is has a patent clause
which would act as a possible barrier to contributing to the docs (which should 
be low)

>   (b) moving text bidirectionally between source code (BSD) and
> documentation (any license)
>   (c) moving text bidirectionally between source code (BSD) and
> documentation (CC0)
> 
> I will raise this at the next SIG meeting

Fundamentally, you can’t move copyrightable content from any CC-BY-4/CC0 to BSD 
and vice versa without going through the process of changing a license

On the community call we discussed Andy's sphinx-docs. Andy made a strong case 
to keep the docset as CC-BY-4
It rests on the assumption that user docs will always be different from what's 
in code and thus there is no need to move anything which is copyrightable 
between code and the docs
Should that turn out to be wrong, there is still always the possibility of a 
mixed CC-BY-4 / BSD-2-Clause docset in future
So we are not painting ourselves into a corner

Regarding safety related docs, we discussed
* CC-BY-4 => this is likely to be problematic as many docs are coupled closely 
with source
* Dual CC-BY-4 / BSD-2-Clause licensing does not solve this problem
* BSD-2-Clause docs would enable docs that 

Thus, the most sensible approach for safety related docs would be to use a 
BSD-2-Clause license uniformly in that case

Regards
Lars

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

Re: [Xen-devel] IMPORTANT CORRECTION - Community Call: Call for Agenda Items and call details for Nov 7, CORRECTED TIME 16:00 - 17:00 UTC

[Lars Kurth]

Hi all,

I tripped over the fact that 
https://www.timeanddate.com/worldclock/meetingdetails.htm uses UTC as fixed 
point whereas my calendar uses the local time as fixed point, so the meeting 
mistakenly got pushed an hour earlier when DST finished. The correct time 
(which should correspond to your calendar entries) is

16:00 - 17:00 UTC
08:00 - 09:00 PST (San Francisco) - sorry for the early time slot. If 
this is a problem, let's discuss at the call
12:00 - 13:00 EST (New York)
16:00 - 17:00 FMT (London)
17:00 - 18:00 CET (Berlin)
23:00 - 01:00 CST (Beijing)
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018&month=11&day=7&hour=16&min=0&sec=0&p1=224&p2=24&p3=179&p4=136&p5=37&p6=33

Best Regards
Lars

On 07/11/2019, 07:24, "Lars Kurth"  wrote:

Hi all,

quick reminder re agenda items. What I have so far is at 
https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/ 

C.1) Any more 4.13 coordination (Juergen)
C.2) Volunteers/suggestions for Release Managers for 4.13 (Lars / Juergen)
C.3) 4.13 Release Notes / Blog Post / Feature List - needs review (Lars)
See 
https://docs.google.com/document/d/1EpigvxDzeoc1dOMFwQ9itDXY4vY7nvxPiLGcNQQmX28/edit?usp=sharing

AOB
1) Travel and discussions
Rich Persaud, Christopher Clark & Daniel Smith will be in Cambridge Dec 10 
pm & 11 am 
Discussions are planned around a number of topics such as state of XSM, 
DomB proposal as a secure means to start an L0/L1 configuration, KCONFIG for L0 
version of Xen, etc.
Citrix will host, but others are welcome to join (please contact Lars for 
logistics)

Feel free to request additional items
    
Regards
Lars

On 04/11/2019, 05:37, "Lars Kurth"  wrote:

Dear community members,
 
please send me agenda items for next week’s community call. A draft 
agenda is at https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/
Please add agenda items to the document or reply to this e-mail
Note that I am on PTO today and tomorrow
 
Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/edit/4FGEw81flPUiivkjkuvQJ-CK/
 
Best Regards
Lars

## Meeting time (please double check the times
15:00 - 16:00 UTC
07:00 - 08:00 PST (San Francisco) - sorry for the early time slot. If 
this is a problem, let's discuss at the call
10:00 - 11:00 EST (New York)
15:00 - 16:00 FMT (London)
16:00 - 17:00 CET (Berlin)
23:00 - 22:00 CST (Beijing)
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018&month=11&day=7&hour=15&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 (Tol

Re: [Xen-devel] Community Call: Call for Agenda Items and call details for Nov 7, 15:00 - 16:00 UTC

[Lars Kurth]

Hi all,

quick reminder re agenda items. What I have so far is at 
https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/ 

C.1) Any more 4.13 coordination (Juergen)
C.2) Volunteers/suggestions for Release Managers for 4.13 (Lars / Juergen)
C.3) 4.13 Release Notes / Blog Post / Feature List - needs review (Lars)
See 
https://docs.google.com/document/d/1EpigvxDzeoc1dOMFwQ9itDXY4vY7nvxPiLGcNQQmX28/edit?usp=sharing

AOB
1) Travel and discussions
Rich Persaud, Christopher Clark & Daniel Smith will be in Cambridge Dec 10 pm & 
11 am 
Discussions are planned around a number of topics such as state of XSM, DomB 
proposal as a secure means to start an L0/L1 configuration, KCONFIG for L0 
version of Xen, etc.
Citrix will host, but others are welcome to join (please contact Lars for 
logistics)

Feel free to request additional items

Regards
Lars

On 04/11/2019, 05:37, "Lars Kurth"  wrote:

Dear community members,
 
please send me agenda items for next week’s community call. A draft agenda 
is at https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/
Please add agenda items to the document or reply to this e-mail
Note that I am on PTO today and tomorrow
 
Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/edit/4FGEw81flPUiivkjkuvQJ-CK/
 
Best Regards
Lars

## Meeting time (please double check the times
15:00 - 16:00 UTC
07:00 - 08:00 PST (San Francisco) - sorry for the early time slot. If this 
is a problem, let's discuss at the call
10:00 - 11:00 EST (New York)
15:00 - 16:00 FMT (London)
16:00 - 17:00 CET (Berlin)
23:00 - 22:00 CST (Beijing)
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018&month=11&day=7&hour=15&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




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

[Xen-devel] Community Call: Call for Agenda Items and call details for Nov 7, 15:00 - 16:00 UTC

[Lars Kurth]

Dear community members,
 
please send me agenda items for next week’s community call. A draft agenda is 
at https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/
Please add agenda items to the document or reply to this e-mail
Note that I am on PTO today and tomorrow
 
Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/edit/4FGEw81flPUiivkjkuvQJ-CK/
 
Best Regards
Lars

## Meeting time (please double check the times
15:00 - 16:00 UTC
07:00 - 08:00 PST (San Francisco) - sorry for the early time slot. If this is a 
problem, let's discuss at the call
10:00 - 11:00 EST (New York)
15:00 - 16:00 FMT (London)
16:00 - 17:00 CET (Berlin)
23:00 - 22:00 CST (Beijing)
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018&month=11&day=7&hour=15&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


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

[Xen-devel] Tagging livepatch-build-tools.git with Xen releases

[Lars Kurth]

Hi all,
I am wondering whether we should tag livepatch-build-tools.git with Xen releases
Best Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference to blktap2

[Lars Kurth]

On 24/10/2019, 12:22, "Wei Liu"  wrote:

On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> On 24.10.19 13:06, Wei Liu wrote:
> > Blktap2 is gone.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> >   CONTRIBUTING | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/CONTRIBUTING b/CONTRIBUTING
> > index 47f53e9a49..4fff4fd9f6 100644
> > --- a/CONTRIBUTING
> > +++ b/CONTRIBUTING
> > @@ -13,7 +13,6 @@ Most of the Xen Project code is licensed under GPLv2, 
but a number of
> >   directories are primarily licensed under different licenses.
> >   Most notably:
> > - - tools/blktap2  : BSD-Modified
> >- tools/libxc: LGPL v2.1
> >- tools/libxl: LGPL v2.1
> >- tools/xl   : LGPL v2.1
> > 
> 
> Mind adding tools/libs instead?

Sure. That can be done.

Because tools/libs' code is mostly split from libxc and friends, I
assume it is going to be LGPL v2.1 as well.

Lars and Ian, your opinion?

Tools/libs does not have a COPYING file, so it is GPL by default. However, all 
the files I checked appear to have LGPL v2.1
So, the directory should probably have an appropriate COPYING file, but we do 
need to check all files in it

Regards
Lars 

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 17/10/2019, 18:05, "Rich Persaud"  wrote:

On Oct 17, 2019, at 12:55, Stefano Stabellini  
wrote:
> 
> On Thu, 17 Oct 2019, Rich Persaud wrote:
>>> On Oct 17, 2019, at 12:32, Stefano Stabellini  
wrote:
>>> 
>>> On Thu, 17 Oct 2019, Lars Kurth wrote:
>>>> On 16/10/2019, 17:35, "Rich Persaud"  wrote:
>>>> 
>>>>>> On Oct 15, 2019, at 08:27, Lars Kurth  
wrote:
>>>>> ...
>>>>> 
>>>>> My point really was is that due to storing the files in git, we 
essentially do NOT today do this.
>>>>> So we would need to take extra action: e.g. manually or through 
tooling
>>>>> 
>>>>>>> 4.2: We could require individual authors to be credited: in that
>>>>>>> case we probably ought to lead by example and list the 
authors
>>>>>>> in a credit/license section and extract the information from
>>>>>>> git logs when we generate it (at some point in the future)
>>>>>>> 5: You give an indication whether you made changes ... in practice
>>>>>>> this means you have to state significant changes made to the works
>>>>>> 
>>>>>> This is also helpful for provenance of changes, which is relevant in 
safety-oriented documentation.  It can be used to clearly delineate CC-licensed 
content (which may be reused by many companies) from "All Rights Reserved" 
commercial content that may be added for a specific commercial audience or 
purpose.
>>>>> 
>>>>> I agree
>>>>> 
>>>>> I think the outcome of this analysis is really that the only 
significant difference between BSD and CC-BY in this context is the  "All 
Rights Reserved" portion
>>>> 
>>>>   Also - BSD is a "software" license while CC-BY is a "content" 
license, so they are not strictly comparable, even if they use similar 
terminology.
>>>> 
>>>> True, but as we have noticed the boundary between content and in-code 
docs content is fuzzy.
>>>> 
>>>>>> There is a difference between "software" which "runs on machines" 
and "documentation" which "runs on humans".  Combined software (e.g. BSD code 
from two origins) is executed identically, despite origin.  Humans make value 
judgements based on the author/origin of content, hence the focus on 
attribution.  Yes, there is a provenance graph in git (software/data), but 
that's not typically visible to human readers, except as a generated report, 
i.e. documentation.
>>>>> 
>>>>> Yes true. But also true for CC-BY-4 sources stored in git unless 
extra action is taken 
>>>>> 
>>>>> But my point is: 
>>>>> * If we take extra action as e.g. proposed in 4.2 we can apply this 
uniformly to BSD as well as CC-BY pages
>>>>> * We can add a section on re-use as proposed in 4.2 which recommends 
best practices around 5.  
>>>>> * We can highlight sections that are BSD vs CC-BY in such a section, 
such that someone who has issue can remove these easily
>>>>> 
>>>>> In addition to these points: maybe it is too impractical to create 
ABI documentation based on CC-BY-4 (given that a lot of what we need is already 
in BSD sources). 
>>>>> We could just copy some of the content in the BSD sources to new 
CC-BY-4 sources, but in practice it would just be hiding the potential legal 
issues behind it. 
>>>>> Someone could contest the creation and argue that portions of the now 
CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, but it 
is possible.
>>>>> 
>>>>>>> As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
>>>>>>> from a downstream's perspective. In fact CC-BY-4 is somewhat 
stricter
>>>>>> 
>>>>>> If we don't want the incentives and provenance properties of CC-BY, 
there is the option of CC0, which is the equivalent of public domain.  This 
would delegate the task of separating commercial vs CC content to each reader, 
without any license-required attribution or separation.
>>>>>> 
>>>>>> Some background on licenses designed for documentation, which has 
different legal requirements than software:
>>>>>> 
  

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 16/10/2019, 17:35, "Rich Persaud"  wrote:

> On Oct 15, 2019, at 08:27, Lars Kurth  wrote:
...
> 
> My point really was is that due to storing the files in git, we 
essentially do NOT today do this.
> So we would need to take extra action: e.g. manually or through tooling
> 
>>>   4.2: We could require individual authors to be credited: in that
>>>   case we probably ought to lead by example and list the authors
>>>   in a credit/license section and extract the information from
>>>   git logs when we generate it (at some point in the future)
>>> 5: You give an indication whether you made changes ... in practice
>>> this means you have to state significant changes made to the works
>> 
>> This is also helpful for provenance of changes, which is relevant in 
safety-oriented documentation.  It can be used to clearly delineate CC-licensed 
content (which may be reused by many companies) from "All Rights Reserved" 
commercial content that may be added for a specific commercial audience or 
purpose.
> 
> I agree
> 
> I think the outcome of this analysis is really that the only significant 
difference between BSD and CC-BY in this context is the  "All Rights Reserved" 
portion

Also - BSD is a "software" license while CC-BY is a "content" license, so 
they are not strictly comparable, even if they use similar terminology.

True, but as we have noticed the boundary between content and in-code docs 
content is fuzzy.

>> There is a difference between "software" which "runs on machines" and 
"documentation" which "runs on humans".  Combined software (e.g. BSD code from 
two origins) is executed identically, despite origin.  Humans make value 
judgements based on the author/origin of content, hence the focus on 
attribution.  Yes, there is a provenance graph in git (software/data), but 
that's not typically visible to human readers, except as a generated report, 
i.e. documentation.
> 
> Yes true. But also true for CC-BY-4 sources stored in git unless extra 
action is taken 
> 
> But my point is: 
> * If we take extra action as e.g. proposed in 4.2 we can apply this 
uniformly to BSD as well as CC-BY pages
> * We can add a section on re-use as proposed in 4.2 which recommends best 
practices around 5.  
> * We can highlight sections that are BSD vs CC-BY in such a section, such 
that someone who has issue can remove these easily
> 
> In addition to these points: maybe it is too impractical to create ABI 
documentation based on CC-BY-4 (given that a lot of what we need is already in 
BSD sources). 
> We could just copy some of the content in the BSD sources to new CC-BY-4 
sources, but in practice it would just be hiding the potential legal issues 
behind it. 
> Someone could contest the creation and argue that portions of the now 
CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, but it 
is possible.
> 
>>> As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
>>> from a downstream's perspective. In fact CC-BY-4 is somewhat stricter
>> 
>> If we don't want the incentives and provenance properties of CC-BY, 
there is the option of CC0, which is the equivalent of public domain.  This 
would delegate the task of separating commercial vs CC content to each reader, 
without any license-required attribution or separation.
>> 
>> Some background on licenses designed for documentation, which has 
different legal requirements than software:
>> 
>> https://www.dreamsongs.com/IHE/IHE-50.html
>> https://creativecommons.org/faq/#what-are-creative-commons-licenses (not 
for s/w)
> 
> I will have a look. But the core issue - which is why I have proposed 
what I have - is the question on how practically ABI documentation published 
under CC-BY-4, when much of this information has already been published in the 
past as code under BSD.

Is there a reference sample of:

- previously published, BSD-licensed, ABI specification-as-source-code

All of http://xenbits.xen.org/docs/unstable/hypercall
And some can be content rich as seen in 
http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,xen.h.html#Func_HYPERVISOR_mmu_update
 
- the corresponding FuSA ABI documentation for that source file

We do NOT have ANY FuSA documentation at this stage. And there are NO examples 
of such docs in the public domain
I am waiting for a sanitised smallish system software example to be made 
available, which should help us identify the practical implications 
However, ABI document

[Xen-devel] Please Welcome Julien Grall as new Security Team Member

[Lars Kurth]

Dear Community members,



I am pleased to announce that Julien Grallh has been nominated and

voted to become a new member of the Xen Project security team.



Julien has made significant contributions to the Xen Project over the

years and has been a maintainer and project leadership team member
for a long time.



Best Regards

Lars Kurth

Xen Project Community Manager

Chairman of Xen Project Advisory Board

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

Hi Rich,

> On 15 Oct 2019, at 02:58, Rich Persaud  wrote:
> 
>> On Oct 11, 2019, at 07:11, Lars Kurth  wrote:
>> 
>> On 11/10/2019, 02:24, "Stefano Stabellini"  wrote:
>> 
>>>On Thu, 10 Oct 2019, Lars Kurth wrote:
>>> 
>>> @Stefano: as you and I believe Brian will be spending time on improving the
>>> ABI docs, I think we need to build some agreement here on what/how
>>> to do it. I was assuming that generally the consensus was to have
>>> docs close to the code in source, but this does not seem to be the case.
>>> 
>>> But if we do have stuff separately, ideally we would have a tool that helps
>>> point people editing headers to also look at the relevant docs. Otherwise 
>>> it will
>>> be hard to keep them in sync.
>> 
>>In general, it is a good idea to keep the docs close to the code to make
>>it easier to keep them up to date. But there is no one-size-fits-all
>>here. For public ABI descriptions, I agree with Andrew that ideally they
>>should not be defined as C header files.
>> 
>>But it is not an issue: any work that we do here won't be wasted. For
>>instance, we could start by adding more comments to the current header
>>files. Then, as a second step, take all the comments and turn them into
>>a proper ABI description document without any C function declarations.
>>It is easy to move English text around, as long as the license allows it
>>-- that is the only potential blocker I can see.
>> 
>> This is likely to be problematic. First of all, we are talking about 
>> BSD-3-Clause
>> or BSD-2-Clause code (the latter is more dominant in headers I believe) in
>> all known cases.
>> 
>> The main properties of the BSD are
>> 1: Can be pretty much used anywhere for any purpose
>> 2: Can be modified for any purpose 
>> 3: But the original license header must be retained in derivates
> 
> This is equivalent to attribution of the copyright owner of the originally 
> created file.
> 
>> Does *not* have requirements around attribution as CC-BY-4: however,
>> as we store everything in git attribution is handled by us by default
> 
> See above, the license header attributes copyright, since BSD was created for 
> "software" and people who work on "software" would typically be looking at 
> source code, hence the primary attribution takes place there, with secondary 
> attribution in EULAs, "About" panels, etc.
> 
>> CC-BY-4 also has properties 1-3
>> In addition: it does require that 
>> 4: Derived works are giving appropriate credit to authors 
>>We could clarify in a COPYING how we prefer to do this
>>4.1: We could say that "referring to the Xen Project community" 
>>is sufficient to comply with the attribution clause
> 
> One motivation for CC-BY (with attribution) is to create an incentive 
> (credit) for the creation of documentation, which is not commonly a favorite 
> pastime of developers.   Credit typically goes at least to the original 
> author of a section of documentation, with varying ways of crediting 
> subsequent contributors.  The documentation can be structured to make 
> crediting easier.  The mechanism for crediting can be designed to encourage 
> specific outcomes, along our projected doc lifecycle for safety 
> certification, contributors, evaluators and commercial investors.

My point really was is that due to storing the files in git, we essentially do 
NOT today do this.
So we would need to take extra action: e.g. manually or through tooling

>>4.2: We could require individual authors to be credited: in that
>>case we probably ought to lead by example and list the authors
>>in a credit/license section and extract the information from
>>git logs when we generate it (at some point in the future)
>> 5: You give an indication whether you made changes ... in practice
>> this means you have to state significant changes made to the works
> 
> This is also helpful for provenance of changes, which is relevant in 
> safety-oriented documentation.  It can be used to clearly delineate 
> CC-licensed content (which may be reused by many companies) from "All Rights 
> Reserved" commercial content that may be added for a specific commercial 
> audience or purpose.

I agree

I think the outcome of this analysis is really that the only significant 
difference between BSD and CC-BY in this context is the  "All Rights Reserved" 
portion

> There is a difference between "software" which "runs on 

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 11/10/2019, 09:32, "Jan Beulich"  wrote:

On 10.10.2019 20:30, Lars Kurth wrote:
> On 10/10/2019, 18:05, "Andrew Cooper"  wrote:
> On 10/10/2019 13:34, Lars Kurth wrote:
> > Existing formats and licenses
> > * Hypercall ABI Documentation generated from Xen public headers
> > Format: kerndoc
> > License: typically BSD-3-Clause (documentation is generated from 
public headers)
> 
> Its homegrown markup&perl, superimposed on what used to be doxygen in
> the past.
> 
> Oh, I forgot
> 
> I wasn't planning on reusing any of the markup, and wasn't expecting 
to
> use much of the text either.  I'm still considering the option of
> defining that xen/public/* isn't the canonical description of the ABI,
> because C is the wrong tool for the job.
> 
> Its fine to provide a C set of headers implementing an ABI, but there 
is
> a very deliberate reason why the canonical migration v2 spec is in a
> text document.
> 
> @Stefano: as you and I believe Brian will be spending time on improving 
the
> ABI docs, I think we need to build some agreement here on what/how
> to do it. I was assuming that generally the consensus was to have
> docs close to the code in source, but this does not seem to be the case.

Well, for migration v2 having the spec in a text file seems sensible
to me. For the public ABI, however, I think it's more helpful to have
the doc next to the actual definitions. Considering the possible use
of languages other than C I can certainly see why separating both
would be even more clean, but I think here we want to weigh practical
purposes against cleanliness.

I think that is an area where we need to build some consensus. The problem
falls under what is considered "traceability" in safety speak: in other words, 
for the ABI documentation use-case it must be easy to be able to
keep documentation and code in sync. And ideally, we would be able to
check this automatically somehow, or have a bot provide hints such as 
"You changed XYZ and should have a look and check whether ABC needs
changing also".

I have thought about the problem of "traceability" for some time, which
goes far beyond what we need for this use-case. Typical things that need
to be maintained for a "traceable (safety) documentation set" are

## Keeping key docs and code in sync 
The use-cases here are things such as
- keep man pages and xl sources in sync
- keep ABI docs and headers in sync
- keep documents such as the migration b2 spec in sync with
  actual source
 
This is a problem we already have today and where we do this often
fairly poorly manually (as can be seen on how out-of-date
man pages often are)

Possible solutions for this are
- store docs alongside headers (maybe using the same base
file name) => that would work for ABI docs

- have some tagging or meta-information scheme which links
specific source files to docs files => that would work for most
other docs (albeit not always perfectly - e.g. when functionality
is spread over many files and just portions of them)

For example: tools/xl/xl_cmdtable.c  
is linked to files in docs/man/xl*

This means creating a bot/tool which warns that when you change
foo.c to also look at foo.rst and/or ../../docs/.../bar.rst should be
relatively straightforward. It would require some initial effort
to create initial mappings, but these would never really change,
unless we refactor code significantly.
 
## Keeping dependent documents (or portions of documents) in sync
This is something we have not really faced, because we do not
have a lot of docs.  

In a large documentation set having the right chapter/tree
structure enables this. In waterfall software engineering
models, where you start off with high-level documents/
requirements/specs/etc. documents which become
increasingly detailed this is done through a chapter/tree
structure, with the capability to make separate documents
(or sections thereof) on other documents (or sections
thereof). When you change something, a tool such as DOORS 
forces you review and sign off child documents.

This is conceptually similar to what we would need for
"linking" sources to docs as outlined above, only that
the "linking" is between docs. It would also be easy enough
to check and highlight, what else may have to be looked at.  

## Proving that your tests verify design claims and that *all claims* are tested
This is typically the hardest problem to solve. It requires
for test cases (be it a document or actual code) to
link to claims (in a design, architecture, spec, ...)
and to prove that all of them are tested.

If there is linkage capability, then it i

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 11/10/2019, 02:24, "Stefano Stabellini"  wrote:

On Thu, 10 Oct 2019, Lars Kurth wrote:
> * Would we ever include API docs generated from GPLv2 code? E.g. for 
safety use-cases?
> @Stefano, @Artem: I guess this one is for you. 
> I suppose if we would have a similar issue for a safety manual
> I am also assuming we would want to use sphinx docs and rst to generate a 
future safety manual

Hi Lars,

Thanks for putting this email together.

In terms of formats, I don't have a preference between rst and pandoc,
but if we are going to use rst going forward, I'd say to try to use rst
for everything, including converting all the old stuff. The fewer
different formats, the better.

I think the proposal that needs to follow on from this (which would at some
point need to be voted on) would then be to go for rst. 

As I mentioned during the FuSa call, I agree with you, Andrew, and
others that it would be best to have the docs under a CC license. I do
expect that we'll end up copy/pasting snippets of in-code comments into
the docs, so I think it is important that we are allowed to do that from
a license perspective. It is great that GPLv2 allows it (we need to be
sure about this).

The GPL does *not* allow this, but (c) law and fair use clauses do. So typically
stuff such as
* Referring to function names, signatures, etc. tend to be all fine
* Copying large portions of in-line comments would not be fine, but
If they are large, they would in most cases be re-written in a more suitable
language. 

So, I think overall, we should be fine. It's a bit of a grey area though.

And as you point out below, most of the code in question is typically BSD 

Yes, I expect that some docs might be automatically generated, but from
header files, not from source code. Especailly public/ header files,
which are typically BSD, not GPLv2. I cannot come up with examples of
docs we need to generated from GPLv2-only code at the moment, hopefully
there won't be any.

That makes things a lot easier.
 
> I wasn't planning on reusing any of the markup, and wasn't expecting 
to
> use much of the text either.  I'm still considering the option of
> defining that xen/public/* isn't the canonical description of the ABI,
> because C is the wrong tool for the job.
> 
> Its fine to provide a C set of headers implementing an ABI, but there 
is
> a very deliberate reason why the canonical migration v2 spec is in a
> text document.
> 
> @Stefano: as you and I believe Brian will be spending time on improving 
the
> ABI docs, I think we need to build some agreement here on what/how
> to do it. I was assuming that generally the consensus was to have
> docs close to the code in source, but this does not seem to be the case.
> 
> But if we do have stuff separately, ideally we would have a tool that 
helps
> point people editing headers to also look at the relevant docs. Otherwise 
it will
> be hard to keep them in sync.

In general, it is a good idea to keep the docs close to the code to make
it easier to keep them up to date. But there is no one-size-fits-all
here. For public ABI descriptions, I agree with Andrew that ideally they
should not be defined as C header files.

But it is not an issue: any work that we do here won't be wasted. For
instance, we could start by adding more comments to the current header
files. Then, as a second step, take all the comments and turn them into
a proper ABI description document without any C function declarations.
It is easy to move English text around, as long as the license allows it
-- that is the only potential blocker I can see.

This is likely to be problematic. First of all, we are talking about 
BSD-3-Clause
or BSD-2-Clause code (the latter is more dominant in headers I believe) in
all known cases.

The main properties of the BSD are
1: Can be pretty much used anywhere for any purpose
2: Can be modified for any purpose 
3: But the original license header must be retained in derivates

Does *not* have requirements around attribution as CC-BY-4: however,
as we store everything in git attribution is handled by us by default

CC-BY-4 also has properties 1-3
In addition: it does require that 
4: Derived works are giving appropriate credit to authors 
We could clarify in a COPYING how we prefer to do this
4.1: We could say that "referring to the Xen Project community" 
is sufficient to comply with the attribution clause
4.2: We could require individual authors to be credited: in that
case we probably ought to lead by example and list the authors
in a credit/license sect

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 10/10/2019, 18:05, "Andrew Cooper"  wrote:

On 10/10/2019 13:34, Lars Kurth wrote:
> Hi all,
>
> following on from a discussion on IRC and on various other places, I 
think we need to try and rationalize how we handle documentation.
>
> What we have now and what we may get in future
> * http://xenbits.xen.org/docs/unstable/ (GPL-2)
> * http://xenbits.xen.org/docs/sphinx-unstable-staging/ (CC-BY-4)
> * Additional API documentation (with a view to enabling safety) 
> * Any future documentation related to safety (requirements, designs, test 
cases, tracability)
>
> Desired licenses
> * There is a desire to keep 
http://xenbits.xen.org/docs/sphinx-unstable-staging/ CC-BY-4 only
> * There is a desire to publish future documentation related to safety as 
CC-BY-4

Its probably worth nothing that the
http://xenbits.xen.org/docs/sphinx-unstable-staging/ URL is only
transitional.

When Sphinx is more ready for primetime, I was thinking of using
http://xenbits.xen.org/docs/xen/, and using the Sphinx support for
multiple versions, which would end up becoming docs/xen/{4.13,...,latest}/

> Existing formats and licenses
> * Hypercall ABI Documentation generated from Xen public headers
> Format: kerndoc
> License: typically BSD-3-Clause (documentation is generated from public 
headers)

Its homegrown markup&perl, superimposed on what used to be doxygen in
the past.

Oh, I forgot

I wasn't planning on reusing any of the markup, and wasn't expecting to
use much of the text either.  I'm still considering the option of
defining that xen/public/* isn't the canonical description of the ABI,
because C is the wrong tool for the job.

Its fine to provide a C set of headers implementing an ABI, but there is
a very deliberate reason why the canonical migration v2 spec is in a
text document.

@Stefano: as you and I believe Brian will be spending time on improving the
ABI docs, I think we need to build some agreement here on what/how
to do it. I was assuming that generally the consensus was to have
docs close to the code in source, but this does not seem to be the case.

But if we do have stuff separately, ideally we would have a tool that helps
point people editing headers to also look at the relevant docs. Otherwise it 
will
be hard to keep them in sync.

> * docs/designs, docs/features, docs/specs
> Formats: primarily pandoc, with some files md
> License: GPL-2
> * docs/processs - covers internal processes
> Formats: txt, with some pandoc
> License: GPL-2
> * docs/figs
> Formats: misc
> License: GPL-2
> * docs/misc
> Formats: txt, with some large number of pandoc, some other docs
> License: GPL-2
> * docs/man
> Formats: pod
> License: GPL-2
> * Sphinx docs: docs, docs/guest-guide, docs/hypervisor-guide
> Formats: rst
> License: CC-BY-4

This is the intention, but hasn't taken effect while my series is still
pending.  For now, strictly speaking it is still GPL-2.

I was basing this on the assumption the series will go in

> * Wiki: 
> Formats: mediawiki markdown
> License: CC-BY-SA-3 which has an automatic update to CC-BY-SA-4
> (c) of Wiki contributions are kept by the authors
>
> This means that the 3 most common file formats in use are
> * pod
> * pandoc (with some md) - these are essentially identical
> * txt for legacy and old stuff
> * rst
>
> License compatibility
> * GPL-2 and CC-BY-4 are compatible, but mixing means that the complete 
docset is GPL-2
> * GPL-2 and BSD-3-Clause are compatible, but mixing means that the 
complete docset is GPL-2
> * BSD-3-Clause and CC-BY-4 I am not 100% sure, but should not be an issue
> * CC-BY-SA-4 is only one way compatible with GPLv3 (affecting content on 
the wiki)
>
> The first question is whether we should convert pod to rst
> * https://metacpan.org/pod/pod2rst provides a conversion tool
> * man pages can be generated by rst2man
> Thus, technically this should be easy and should make contributions to 
docs/man easier
> If we do this, we should add a CONTRIBUTING file, clarifying the license 
in this directory

One thing I have done is put SPDX tags on every *.rst file.  What I
haven't found is a nice way to insert one into the *.drawio.svg files,
but I should probably finish off some of my experimentation TODOs.

An easy way out is to just say "look at the SPDX tag", but then we end
up with a docset which is a mess of licenses, still can't be easily
built upon.

I think a per-directory app

[Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

Hi all,

following on from a discussion on IRC and on various other places, I think we 
need to try and rationalize how we handle documentation.

What we have now and what we may get in future
* http://xenbits.xen.org/docs/unstable/ (GPL-2)
* http://xenbits.xen.org/docs/sphinx-unstable-staging/ (CC-BY-4)
* Additional API documentation (with a view to enabling safety) 
* Any future documentation related to safety (requirements, designs, test 
cases, tracability)

Desired licenses
* There is a desire to keep 
http://xenbits.xen.org/docs/sphinx-unstable-staging/ CC-BY-4 only
* There is a desire to publish future documentation related to safety as CC-BY-4

Existing formats and licenses
* Hypercall ABI Documentation generated from Xen public headers
Format: kerndoc
License: typically BSD-3-Clause (documentation is generated from public headers)
* docs/designs, docs/features, docs/specs
Formats: primarily pandoc, with some files md
License: GPL-2
* docs/processs - covers internal processes
Formats: txt, with some pandoc
License: GPL-2
* docs/figs
Formats: misc
License: GPL-2
* docs/misc
Formats: txt, with some large number of pandoc, some other docs
License: GPL-2
* docs/man
Formats: pod
License: GPL-2
* Sphinx docs: docs, docs/guest-guide, docs/hypervisor-guide
Formats: rst
License: CC-BY-4

* Wiki: 
Formats: mediawiki markdown
License: CC-BY-SA-3 which has an automatic update to CC-BY-SA-4
(c) of Wiki contributions are kept by the authors

This means that the 3 most common file formats in use are
* pod
* pandoc (with some md) - these are essentially identical
* txt for legacy and old stuff
* rst

License compatibility
* GPL-2 and CC-BY-4 are compatible, but mixing means that the complete docset 
is GPL-2
* GPL-2 and BSD-3-Clause are compatible, but mixing means that the complete 
docset is GPL-2
* BSD-3-Clause and CC-BY-4 I am not 100% sure, but should not be an issue
* CC-BY-SA-4 is only one way compatible with GPLv3 (affecting content on the 
wiki)

The first question is whether we should convert pod to rst
* https://metacpan.org/pod/pod2rst provides a conversion tool
* man pages can be generated by rst2man
Thus, technically this should be easy and should make contributions to docs/man 
easier
If we do this, we should add a CONTRIBUTING file, clarifying the license in 
this directory

There are a set of related questions on what we would eventually merge into the 
sphinx
docset. I believe there is agreement that most of what is in docs today is not 
really
suitable, however there are a few possible exceptions
* man pages - with a variety of different contributors from different orgs. 
Changing license would be hard 
* API docs generated from PUBLIC headers - changing license would be 
impossible, but would be BSD-3-Clause
* Some wiki content (e.g. 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches and friends) 
   More than 95% of changes were from Citrix staff, so we could convert to 
CC-BY-4
   Most non-Citrix changes are one-line changes and could be covered by fair use
* Possibly stuff such as 
https://xenbits.xen.org/docs/unstable/support-matrix.html (which is currently 
GPL-2,
   but we could relicense to say GPL-2 and CC-BY-4 if we had to)
The implication is that the sphinx docs would not be fully CC-BY-4, but the 
bulk of the pages would be

* Would we ever include API docs generated from GPLv2 code? E.g. for safety 
use-cases?
@Stefano, @Artem: I guess this one is for you. 
I suppose if we would have a similar issue for a safety manual
I am also assuming we would want to use sphinx docs and rst to generate a 
future safety manual

Other pages in docs that may be useful for the sphinx docs should essentially 
be re-written, 
so we would be fine from a licensing perspective. That means that over time, we 
could get rid of 
pandoc and text files in docs/misc, docs/designs, docs/features, docs/specs 
which
have not really built a lot of traction.

Related to this is the general question, whether we would ever copy code from 
source to docs
and vice versa and to which degree. This is an unknown to me: I think in 
practice we have not seen
much or even any of this in the past.

On licensing, we should try and make the docs directory clean, e.g.
* We should set the default to CC-BY-4 (e.g. through a contributing file in 
docs)
* And specifically use GPL-2 for directories such as docs/misc, docs/man, ...

In any case, this seems all a little bit of a mess at the moment and I think we 
need to
agree on a foundation to get us to a better state. This mail is a start and 
intends to gather
input and will eventually lead to a more concrete proposal.

If I have missed anything, feel free to add

Best Regards
Lars



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

Re: [Xen-devel] [PATCH] read grubenv and set default from saved_entry or next_entry [and 1 more messages]

[Lars Kurth]

> On 7 Oct 2019, at 11:01, Ian Jackson  wrote:
> 
> Hi.  Thanks for the message.
> 
> Just one thing I wanted to reply to in your mail:
> 
> YOUNG, MICHAEL A. writes ("Re: [Xen-devel] [PATCH] read grubenv and set 
> default from saved_entry or next_entry [and 1 more messages]"):
>> On Wed, 11 Sep 2019, Ian Jackson wrote:
>>> I find this filename hackery rather unprincipled.  I'm not entirely
>>> sure I can see a better way, given the way cfg_list is constructed.
>>> Can you think of a less hacky approach ?
> ...
>> One option would be to do a fresh search for grubenv in the same places
>> we looked for grub.cfg.
>> 
>> Alternatively, it should be possible to do a more precise edit using
>> f.rpartition("/").
> 
> I don't feel I fully understand the implications, but either of these
> seems like they might be good strategies to me.  I guess the former
> risks finding an unrelated leftover grubenv somewhere which is
> probably not desirable.
> 
> Anyway, I will leave this to your judgement.
> 
> Thanks for the rest of your comments.  I'll look forward to a revised
> set of patches - thanks.

Hi all,

I am assuming there is no chance that this will make 4.13 with the freeze 
having passed.

But in any case, I wasn't sure whether Michael strictly will need it as the 
change can presumably be carried in a fedora patch q for Xen packages until it 
ends up upstream

Lars



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

Re: [Xen-devel] [PATCH 1/4] docs/sphinx: License content with CC-BY-4.0

[Lars Kurth]

On 03/10/2019, 21:56, "Andrew Cooper"  wrote:

Creative Commons is a more common license than GPL for documentation 
purposes.
Switch to using CC-BY-4.0 to explicitly permit re-purposing and remixing of
the content.

Signed-off-by: Andrew Cooper 

Reviewed-by: Lars Kurth 

Also, I need to clarify that one of the statements I made yesterday is wrong
CC-BY-4 is compatible with all versions with of the GPL, see
https://www.gnu.org/licenses/license-list.en.html#OtherLicenses

I mixed up CC-BY-4 with CC-BY-SA-4
 

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

Re: [Xen-devel] [PATCH 3/4] docs/sphinx: Introduction

[Lars Kurth]

On 03/10/2019, 21:59, "Andrew Cooper"  wrote:

Put together an introduction page for the Sphinx/RST docs, along with a
glossary which will accumulate over time.

Signed-off-by: Andrew Cooper 

Reviewed-by: Lars Kurth 

There were a few minor improvements which could be made, I am listing these
below, but none are show-stoppers.

+Xen is an open source, bare metal hypervisor.  It runs as the most 
privileged
+piece of software, and shares the resources of the hardware between virtual
Maybe better: s/software/software on the system/ or s/software/software on the 
host/
+machines.

+   hardware domain
+ A :term:`domain`, commonly dom0, which shares responsibility with Xen
+ about the system as a whole.
+
+ By default it gets all devices, including all disks and network 
cards, so
+ is responsible for multiplexing guest I/O

This is a little unclear: in particular the 1st paragraph. Earlier you talk 
about hardware
domain="responsible for hardware and marshalling guest I/O", which is clearer. 

Maybe: 

A :term:`domain`, commonly dom0, which hosts all devices, including disks
and network cards and is responsible for multiplexing guest I/O

is better

Regards
Lars
 

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

Re: [Xen-devel] [PATCH 2/4] docs/sphinx: Indent cleanup

[Lars Kurth]

On 03/10/2019, 21:56, "Andrew Cooper"  wrote:

Sphinx, its linters, and RST modes in common editors, expect 3 spaces of
indentation.  Some bits already conform to this expectation.  Update the
rest to match.

Signed-off-by: Andrew Cooper 

Reviewed-by: Lars Kurth 


___
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 Oct, 10th Community Call @ 15:00 UTC - One week later than normal - different dial-in details

[Lars Kurth]

Hi all,
I won't be able to kick off the call on Thursday, but should be able to join 
the last 30 minutes of the call. Juergen has volunteered to kick off and 
moderate the call, but to do this we have to change the dial-in details. Please 
use the following details

https://www.gotomeet.me/JuergenGross

You can also dial in using your phone.
United States (Toll Free): 1 866 899 4679
United States: +1 (646) 749-3117

Access Code: 133-463-709

More phone numbers
Argentina (Toll Free): 0 800 444 2385
Australia (Toll Free): 1 800 191 358
Australia: +61 2 8355 1038
Austria (Toll Free): 0 800 202144
Austria: +43 7 2081 5337
Bahrain (Toll Free): 800 81 305
Belarus (Toll Free): 8 820 0073 0071
Belgium (Toll Free): 0 800 78881
Belgium: +32 28 93 7002
Brazil (Toll Free): 0 800 047 4902
Brazil: +55 11 4118-4898
Bulgaria (Toll Free): 00800 120 4413
Canada (Toll Free): 1 888 299 1889
Canada: +1 (647) 497-9373
Chile (Toll Free): 800 395 146
China (Toll Free): 4006 037937
Colombia (Toll Free): 01 800 012 9057
Costa Rica (Toll Free): 0800 542 5404
Czech Republic (Toll Free): 800 143570
Denmark (Toll Free): 8025 3112
Denmark: +45 32 72 03 69
Finland (Toll Free): 0 800 917643
Finland: +358 942 72 0972
France (Toll Free): 0 805 541 052
France: +33 170 950 590
Germany (Toll Free): 0 800 723 5274
Germany: +49 692 5736 7300
Greece (Toll Free): 00 800 4414 4282
Hong Kong (Toll Free): 800 900 221
Hungary (Toll Free): (06) 80 986 259
Iceland (Toll Free): 800 7206
India (Toll Free): 18002669775
Indonesia (Toll Free): 001 803 852 9155
Ireland (Toll Free): 1 800 818 263
Ireland: +353 15 295 146
Israel (Toll Free): 1 809 453 019
Italy (Toll Free): 800 792289
Italy: +39 0 230 57 81 80
Japan (Toll Free): 0 120 242 200
Korea, Republic of (Toll Free): 00798 14 207 4828
Luxembourg (Toll Free): 800 29524
Malaysia (Toll Free): 1 800 81 6860
Mexico (Toll Free): 01 800 083 5535
Mexico: +52 55 4624 4518
Netherlands (Toll Free): 0 800 023 1954
Netherlands: +31 207 941 375
New Zealand (Toll Free): 0 800 47 0051
New Zealand: +64 9 282 9510
Norway (Toll Free): 800 33 083
Norway: +47 21 93 37 37
Panama (Toll Free): 00 800 203 0002
Peru (Toll Free): 0 800 55465
Philippines (Toll Free): 1 800 1110 1669
Poland (Toll Free): 00 800 1124748
Portugal (Toll Free): 800 819 683
Romania (Toll Free): 0 800 400 826
Russian Federation (Toll Free): 8 800 100 6216
Saudi Arabia (Toll Free): 800 844 3636
Singapore (Toll Free): 18007231322
Slovakia (Toll Free): 0 800 132 608
South Africa (Toll Free): 0 800 555 451
Spain (Toll Free): 800 900 593
Spain: +34 932 75 1230
Sweden (Toll Free): 0 200 330 924
Sweden: +46 853 527 818
Switzerland (Toll Free): 0 800 000 452
Switzerland: +41 225 4599 60
Taiwan (Toll Free): 0 800 666 846
Thailand (Toll Free): 001 800 658 129
Turkey (Toll Free): 00 800 4488 29001
Ukraine (Toll Free): 0 800 60 9142
United Arab Emirates (Toll Free): 800 044 40444
United Kingdom (Toll Free): 0 800 389 5276
United Kingdom: +44 20 3713 5011
Uruguay (Toll Free): 0004 019 1017
Viet Nam (Toll Free): 120 32 148

Join from a video-conferencing room or system.
Dial in or type: 67.217.95.2 or inroomlink.goto.com
Meeting ID: 133 463 709
Or dial directly: 133463709@67.217.95.2 or 67.217.95.2##133463709

New to GoToMeeting? Get the app now and be ready when your first meeting
starts:
https://global.gotomeeting.com/install/133463709

Regards
Lars

On 27/09/2019, 14:56, "Lars Kurth"  wrote:

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
Czec

Re: [Xen-devel] [PATCH 1/4] docs/sphinx: License content with CC-BY-4.0

[Lars Kurth]

On 07/10/2019, 13:29, "Andrew Cooper"  wrote:

On 07/10/2019 13:01, Lars Kurth wrote:
>
> On 03/10/2019, 21:56, "Andrew Cooper"  wrote:
>
> Creative Commons is a more common license than GPL for documentation 
purposes.
> Switch to using CC-BY-4.0 to explicitly permit re-purposing and 
remixing of
> the content.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Lars Kurth 
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Wei Liu 
> CC: Julien Grall 
> CC: Rich Persaud 
> CC: Juergen Gross 
> ---
>  COPYING |  3 +++
>  docs/README.source  | 32 

>  docs/admin-guide/index.rst  |  2 ++
>  docs/admin-guide/microcode-loading.rst  |  2 ++
>  docs/conf.py|  1 +
>  docs/guest-guide/index.rst  |  2 ++
>  docs/guest-guide/x86/hypercall-abi.rst  |  2 ++
>  docs/guest-guide/x86/index.rst  |  2 ++
>  docs/hypervisor-guide/code-coverage.rst |  2 ++
>  docs/hypervisor-guide/index.rst |  2 ++
>  docs/index.rst  |  2 ++
>  11 files changed, 52 insertions(+)
>  create mode 100644 docs/README.source
> 
> diff --git a/COPYING b/COPYING
> index 310fd52c27..80fac091d3 100644
> --- a/COPYING
> +++ b/COPYING
> @@ -47,6 +47,9 @@ various drivers, support functions and header files 
within Xen-aware
>  Linux source trees. In all such cases, license terms are stated at 
the
>  top of the file or in a COPYING file in the same directory.
>  
> +Sphinx documentation is licensed under CC-BY 4.0.  See
> +docs/README.source for more specific information.
> +
>  In some cases, compatible 3rd party code has been imported into the
>  Xen tree, retaining the original license, such as
>- AES-128 3.0
> diff --git a/docs/README.source b/docs/README.source
> new file mode 100644
> index 00..f20fa92c28
> --- /dev/null
> +++ b/docs/README.source
> @@ -0,0 +1,32 @@
> +Sphinx documentation:
> +
> +All source rendered by Sphinx is licensed under CC-BY-4.0.
>
> Sorry for opening this can of worms. 
>
> Although I had seen the discussion between Rich and you about this, I had 
> not actually done any groundwork on the licensing. 
>
> So, we have to look at two things:
>
> * Compatibility:
>See 
https://creativecommons.org/2015/10/08/cc-by-sa-4-0-now-one-way-compatible-with-gplv3/
 
>This makes CC-BY-4.0 inbound compatible with GPLv3
>It's not clear to me whether GPLv2 is compatible with CC-BY 4.0: lack 
of publicly
>available information implies this is not the case 
>
> * Output License
>But even if it is, the produced sphinx output would be GPLv2, not 
CC-BY 4.0
>This would even be true if none of the older GPLv2 docs portions were 
included, as
>the API docs generated from source are GPLv2
>
> As such the statement "All source rendered by Sphinx is licensed under
> CC-BY-4.0" is wrong.

At the moment, I (and therefore Citrix in practice) holds the copyright
on all rst content which exists in Xen.

The point of this patch is to get it licensed sensibly (and in
particular, not falling back to the GPL default) before 4.13 goes out of
the door.

The result therefore is uniformly CC-BY-4.0, with no GPL in sight.

Having looked at this again, you are correct. I was assuming that 
https://andrewcoop-xen.readthedocs.io/en/docs-devel/guest-guide/x86/hypercall-abi.html
was linking to the doxygen generated ABI docs, which it seems not to do.

> Although it is probably correct to say "All CC-BY 4.0 source rendered by
> Sphinx is licensed under CC-BY-4.0", because Sphinx retains the source 
file
> to html mapping and linkage in docs generation works differently
> to linkage in code. 
>
> I am wondering whether anyone else has come across this. This question in
> particular goes back to Rich who made a very strong case for CC-BY-4.0 
based
> documentation. I don't think we would have an issue if the entire sphinx 
doc-set
> is GPLv2 if most content is 

Re: [Xen-devel] [PATCH 1/4] docs/sphinx: License content with CC-BY-4.0

[Lars Kurth]

On 03/10/2019, 21:56, "Andrew Cooper"  wrote:

Creative Commons is a more common license than GPL for documentation 
purposes.
Switch to using CC-BY-4.0 to explicitly permit re-purposing and remixing of
the content.

Signed-off-by: Andrew Cooper 
---
    CC: Lars Kurth 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
CC: Rich Persaud 
CC: Juergen Gross 
---
 COPYING |  3 +++
 docs/README.source  | 32 

 docs/admin-guide/index.rst  |  2 ++
 docs/admin-guide/microcode-loading.rst  |  2 ++
 docs/conf.py|  1 +
 docs/guest-guide/index.rst  |  2 ++
 docs/guest-guide/x86/hypercall-abi.rst  |  2 ++
 docs/guest-guide/x86/index.rst  |  2 ++
 docs/hypervisor-guide/code-coverage.rst |  2 ++
 docs/hypervisor-guide/index.rst |  2 ++
 docs/index.rst  |  2 ++
 11 files changed, 52 insertions(+)
 create mode 100644 docs/README.source

diff --git a/COPYING b/COPYING
index 310fd52c27..80fac091d3 100644
--- a/COPYING
+++ b/COPYING
@@ -47,6 +47,9 @@ various drivers, support functions and header files 
within Xen-aware
 Linux source trees. In all such cases, license terms are stated at the
 top of the file or in a COPYING file in the same directory.
 
+Sphinx documentation is licensed under CC-BY 4.0.  See
+docs/README.source for more specific information.
+
 In some cases, compatible 3rd party code has been imported into the
 Xen tree, retaining the original license, such as
   - AES-128 3.0
diff --git a/docs/README.source b/docs/README.source
new file mode 100644
index 00..f20fa92c28
--- /dev/null
+++ b/docs/README.source
@@ -0,0 +1,32 @@
+Sphinx documentation:
+
+All source rendered by Sphinx is licensed under CC-BY-4.0.

Sorry for opening this can of worms. 

Although I had seen the discussion between Rich and you about this, I had 
not actually done any groundwork on the licensing. 

So, we have to look at two things:

* Compatibility:
   See 
https://creativecommons.org/2015/10/08/cc-by-sa-4-0-now-one-way-compatible-with-gplv3/
 
   This makes CC-BY-4.0 inbound compatible with GPLv3
   It's not clear to me whether GPLv2 is compatible with CC-BY 4.0: lack of 
publicly
   available information implies this is not the case 

* Output License
   But even if it is, the produced sphinx output would be GPLv2, not CC-BY 4.0
   This would even be true if none of the older GPLv2 docs portions were 
included, as
   the API docs generated from source are GPLv2

As such the statement "All source rendered by Sphinx is licensed under
CC-BY-4.0" is wrong. 

Although it is probably correct to say "All CC-BY 4.0 source rendered by
Sphinx is licensed under CC-BY-4.0", because Sphinx retains the source file
to html mapping and linkage in docs generation works differently
to linkage in code. 

I am wondering whether anyone else has come across this. This question in
particular goes back to Rich who made a very strong case for CC-BY-4.0 based
documentation. I don't think we would have an issue if the entire sphinx doc-set
is GPLv2 if most content is licensed under CC-BY-4.0, except that such an
approach would make re-using the entire sphinx generated docset messy.

We probably also want to maintain the capability to copy text from some
documentation freely into the source tree and vice versa, if needed. This is
particularly true for content in Technical Debt, user content (may end up in
man pages), etc.

Maybe the right approach would be to dually license the documentation
files using both GPLv2 and CC-BY 4.0 and quantifying this in the COPYING
file of the docs directory (starting from a specific date). We could eventually
re-license all the other stuff over time, which should be relatively 
straightforward
and/or exclude specific problematic directories.

Things like standardising say man pages to rst, would potentially also
create complexities with this patch, because of 
+This includes:
+  * All ReStructured Text files:  docs/*/*.rst

I don't want this to become a long-winded conversation during the 4.13 freeze.
Please keep this in mind when responding.

It may mean though, that we can't resolve this before 4.13 is released

Regards
Lars

 

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

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

[Lars Kurth]

On 07/10/2019, 12:06, "George Dunlap"  wrote:

On 9/26/19 8:39 PM, Lars Kurth wrote:
    > 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.

This is relatively minor, but I don't feel quite comfortable with the
wording.  "pledge to make it a harassment-free experience" to me implies
that we pledge that *nobody will ever experience harassment*.  I don't
think that's something we can deliver, any more than a government can
promise there will be zero crime.  I think we could promise to
*maintain* a harassment-free experience, which implies things to a
restoring harassment-free state after it's been broken.

Everything else looks good.

Could you come up with an alternative concrete text proposal? 

My take-away is that you say we should use
* "pledge to strive to make ..." or 
* "pledge to try their best to make ..." or
* "strive to make ..." 
in which case we may also need to change "The Pledge".

On the other hand: the rest of the document does clearly lay out that
what we promise is to deal with incidents in an effective manner.
And by the mere inclusion of mechanism to do this, it is actually clear
that we can't guarantee that *nobody will ever experience harassment*.

I guess it comes down to subtleties of how pledge, promise, strive, ...
differ

Regards
Lars
 



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

Re: [Xen-devel] [PATCH for-4.13] docs: update all URLs in man pages

[Lars Kurth]

On 07/10/2019, 10:01, "Wei Liu"  wrote:

On Mon, 7 Oct 2019 at 09:13, Lars Kurth  wrote:
>
>
>
> On 04/10/2019, 09:57, "Wei Liu"  wrote:
>
> On Thu, Oct 03, 2019 at 04:12:30PM +, Lars Kurth wrote:
> > Specifically
> > * xen.org to xenproject.org
> > * http to https
> > * Replaced pages where page has moved
> >   (including on xen pages as well as external pages)
> > * Removed some URLs (e.g. downloads for Linux PV drivers)
>     >
> > Tested-by: Lars Kurth 
> > Signed-off-by: Lars Kurth 
>
> Do you have a branch for this patch?
>
> Unfortunately, not: I never created a personal copy of xen.git on xenbits
> Really should do this

Please do. I couldn't reply this patch cleanly. Not sure why git
wasn't happy about it.

Wei.

Hi Wei,

I fixed the missing http link and rebased to staging
See 
http://xenbits.xen.org/gitweb/?p=people/larsk/xen.git;a=commit;h=088c2781795c5924cd1fc7f11f3d31154d866799
 & 
http://xenbits.xen.org/gitweb/?p=people/larsk/xen.git;a=shortlog;h=refs/heads/docs-changes-4.13-v2
 

When rebasing there was no conflict, so not sure why it didn't apply for you

Regards
Lars

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

Re: [Xen-devel] [PATCH for-4.13] docs: update all URLs in man pages

[Lars Kurth]

On 04/10/2019, 09:57, "Wei Liu"  wrote:

On Thu, Oct 03, 2019 at 04:12:30PM +0000, Lars Kurth wrote:
> Specifically
> * xen.org to xenproject.org
> * http to https
> * Replaced pages where page has moved
>   (including on xen pages as well as external pages)
> * Removed some URLs (e.g. downloads for Linux PV drivers)
    > 
> Tested-by: Lars Kurth 
> Signed-off-by: Lars Kurth 

Do you have a branch for this patch?

Unfortunately, not: I never created a personal copy of xen.git on xenbits
Really should do this
Lars



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

[Xen-devel] [PATCH for-4.13] docs: update all URLs in man pages

[Lars Kurth]

Specifically
* xen.org to xenproject.org
* http to https
* Replaced pages where page has moved
  (including on xen pages as well as external pages)
* Removed some URLs (e.g. downloads for Linux PV drivers)

Tested-by: Lars Kurth 
Signed-off-by: Lars Kurth 
---
 docs/man/xen-pci-device-reservations.7.pod |  2 +-
 docs/man/xen-pv-channel.7.pod  |  2 +-
 docs/man/xen-vtpm.7.pod|  2 +-
 docs/man/xenstore-chmod.1.pod  |  4 ++--
 docs/man/xenstore-ls.1.pod |  4 ++--
 docs/man/xenstore-read.1.pod   |  4 ++--
 docs/man/xenstore-write.1.pod  |  4 ++--
 docs/man/xenstore.1.pod|  4 ++--
 docs/man/xentop.1.pod  |  2 +-
 docs/man/xl-disk-configuration.5.pod   |  4 ++--
 docs/man/xl-network-configuration.5.pod|  8 
 docs/man/xl-numa-placement.7.pod   |  4 ++--
 docs/man/xl.1.pod.in   | 22 +++---
 docs/man/xl.cfg.5.pod.in   | 20 ++--
 docs/man/xl.conf.5.pod |  4 ++--
 docs/man/xlcpupool.cfg.5.pod   |  4 ++--
 16 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/docs/man/xen-pci-device-reservations.7.pod 
b/docs/man/xen-pci-device-reservations.7.pod
index 0df41bcd29..bc7398409c 100644
--- a/docs/man/xen-pci-device-reservations.7.pod
+++ b/docs/man/xen-pci-device-reservations.7.pod
@@ -29,7 +29,7 @@ multiple Xen vendors using conflicting IDs.
 
 =item 3. The vendor is responsible for allocations within the range and should
  try to record specific device IDs in PCI ID databases such as
- http://pciids.sourceforge.net and http//www.pcidatabase.com
+ http://pci-ids.ucw.cz and https://devicehunt.com
 
 =back
 
diff --git a/docs/man/xen-pv-channel.7.pod b/docs/man/xen-pv-channel.7.pod
index 07898f6dde..ab4577d1da 100644
--- a/docs/man/xen-pv-channel.7.pod
+++ b/docs/man/xen-pv-channel.7.pod
@@ -186,4 +186,4 @@ that no-one's name clashes with yours, please add yours to 
this list.
 N: org.xenproject.guest.clipboard.0.1
 C: David Scott 
 D: Share clipboard data via an in-guest agent. See:
-   http://wiki.xenproject.org/wiki/Clipboard_sharing_protocol
+   https://wiki.xenproject.org/wiki/Clipboard_sharing_protocol
diff --git a/docs/man/xen-vtpm.7.pod b/docs/man/xen-vtpm.7.pod
index 1d8185616a..d033072584 100644
--- a/docs/man/xen-vtpm.7.pod
+++ b/docs/man/xen-vtpm.7.pod
@@ -380,4 +380,4 @@ C will copy pcrs 5, 12, 13, 14, 15, and 
16.
 
 =head1 REFERENCES
 
-Berlios TPM Emulator: L<http://tpm-emulator.berlios.de/>
+Berlios TPM Emulator: L<https://github.com/PeterHuewe/tpm-emulator>
diff --git a/docs/man/xenstore-chmod.1.pod b/docs/man/xenstore-chmod.1.pod
index cb1dc2ef82..d76f34723d 100644
--- a/docs/man/xenstore-chmod.1.pod
+++ b/docs/man/xenstore-chmod.1.pod
@@ -58,5 +58,5 @@ Apply the permissions to the key and all its I.
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore-ls.1.pod b/docs/man/xenstore-ls.1.pod
index e04a509fa7..8dac931e94 100644
--- a/docs/man/xenstore-ls.1.pod
+++ b/docs/man/xenstore-ls.1.pod
@@ -58,5 +58,5 @@ Connect to the Xenstore daemon using a local socket only.
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore-read.1.pod b/docs/man/xenstore-read.1.pod
index 5496de17a8..f5a7bb7e46 100644
--- a/docs/man/xenstore-read.1.pod
+++ b/docs/man/xenstore-read.1.pod
@@ -28,5 +28,5 @@ Read raw value, skip escaping non-printable characters (\x..).
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore-write.1.pod b/docs/man/xenstore-write.1.pod
index 78cbbe1a69..d1b011236a 100644
--- a/docs/man/xenstore-write.1.pod
+++ b/docs/man/xenstore-write.1.pod
@@ -25,5 +25,5 @@ Write raw value, skip parsing escaped characters (\x..).
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore.1.pod b/docs/man/xenstore.1.pod
index dd8f80647d..ab9fb4a79c 100644
--- a/docs/man/xenstore.1.pod
+++ b/docs/m

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

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] [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, 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

[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

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