[MirageOS-devel] Help Needed project list is stale - needs updating for GSoC

[Lars Kurth]

Hi all,

we are applying for GSoC again this year

I noticed that  http://canopy.mirage.io/tags/help%20needed is totally stale. 
Can you please update this and also update it in such a way that
a) The list of mentors is clear, e.g. use a format like
Mentor: name, email address: , IRC handle: 
b) Contains some meta information, such as
Difficulty: Easy/Medium/Hard
c) Provide a more thorough project description
E.g. something like 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#golang_consumer_for_the_.60xenlight.60_golang_package

I would need this in place by Feb 7

If the list stays as it is, I will remove Mirage OS from 
https://wiki.xenproject.org/wiki/Outreach_Program_Project. You would still be 
able to add your projects to 
https://wiki.xenproject.org/wiki/Outreach_Program_Project, which would be my 
preference anyway

Do let me know if you need any help

Best Regards
Lars
P.S.: Not that I am changing the Project template to include *IRC* / *List*  
fields
___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

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-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

[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

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





___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

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

Re: [MirageOS-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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

[Xen-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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-API] [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://stackoverflow.com/questions/4823468/comments-in-markdown 
‹gwd›  lars_kurth: That's what I wou

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://stackoverflow.com/questions/4823468/comments-in-markdown 
‹gwd›  lars_kurth: That's what I wou

Re: [MirageOS-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://stackoverflow.com/questions/4823468/comments-in-markdown 
‹gwd›  lars_kurth: That's what I wou

Re: [Xen-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

Re: [MirageOS-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



___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

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=1=9=16=0=0=224=24=179=136=37=33

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check


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

Re: [Xen-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

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

Re: [MirageOS-devel] [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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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 askin

[MirageOS-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-devel@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 askin

[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

[MirageOS-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-devel@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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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
+* 
+are also important during code reviews.
+
+### Style
+
+* Comments, carriage returns, **snuggly braces**, 
+* 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 build

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

[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 to the level of
+per

[MirageOS-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-devel@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
+* 
+are also important during code reviews.
+
+### Style
+
+* Comments, carriage returns, **snuggly braces**, 
+* 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 build

[MirageOS-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-devel@lists.xenproject.org
Cc: committ...@xenproject.org
---
 code-of-conduct.md | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

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

[MirageOS-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-devel@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

___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

[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-decisions
+
 ## Attr

[MirageOS-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-devel@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 to the level of
+per

Re: [Xen-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

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-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

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

___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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 fulfil befor

[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 to a r

[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

[MirageOS-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-devel@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 to a r

[MirageOS-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-devel@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 fulfil befor

[MirageOS-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-devel@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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

[MirageOS-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-devel@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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

[MirageOS-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-devel@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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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://xenproject.org/d

[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
+* 
+are also important during code reviews.
+
+### Style
+
+* Comments, carriage returns, **snuggly braces**, 
+* 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
+  subsystem of your tree. If your chan

[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

[MirageOS-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-devel@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
+* 
+are also important during code reviews.
+
+### Style
+
+* Comments, carriage returns, **snuggly braces**, 
+* 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
+  subsystem of your tree. If your chan

[MirageOS-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-devel@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://xenproject.org/d

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

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
> is covered i

Re: [MirageOS-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
> is covered i

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 uncover issues such as wrong or missed 

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=12=5=16=0=0=224=24=179=136=37=33

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check






___
Xe

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=12=5=16=0=0=224=24=179=136=37=33

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check




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

[Xen-devel] 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=12=4=16=0=0=224=24=179=136=37=33

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check


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

Re: [Xen-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

Re: [MirageOS-devel] [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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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: [MirageOS-devel] [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

___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-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-API] [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-api@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 also did Y" doesn

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 also did Y" doesn

Re: [MirageOS-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-devel@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 also did Y" doesn

Re: [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-devel@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

___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

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-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

Re: [Xen-API] [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-api@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 p

Re: [MirageOS-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



___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

Re: [MirageOS-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-devel@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 p

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 p

Re: [Xen-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

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

___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

Re: [Xen-API] [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-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api

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: [MirageOS-devel] [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


___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel