Re: Event delivery and "domain blocking" on PVHv2

On 22.06.2020 18:09, Roger Pau Monné wrote: > On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote: >> On 2020-06-22 15:58, Roger Pau Monné wrote: >>> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: Aha! Thank you for pointing this out. I think you may be right, but

Re: Event delivery and "domain blocking" on PVHv2

On 22.06.2020 17:31, Martin Lucina wrote: > On 2020-06-22 15:58, Roger Pau Monné wrote: >> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: >>> How about this arrangement, which appears to work for me; no hangs I >>> can see >>> so far and domU survives ping -f fine with no packet

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

On 17.01.2020 20:12, Lars Kurth wrote: > 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). I have to admit that wit

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

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

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

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

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

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,

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

On 28.11.2019 01:56, Stefano Stabellini wrote: > On Thu, 26 Sep 2019, Lars Kurth wrote: >> +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

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

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

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

On 07.10.2019 18:13, George Dunlap wrote: > On 9/27/19 10:14 AM, 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 >>>

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

On 27.09.2019 12:17, Lars Kurth wrote: > Can I maybe get you to reconsider and re-review the next version from the > view point of an author and maybe make suggestions on how to create more > balance I'll certainly make an attempt. Jan ___

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

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:

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

On 26.09.2019 21:39, Lars Kurth wrote: > +### Express appreciation > +As the nature of code review to find bugs and possible issues, it is very > easy for > +reviewers to get into a mode of operation where the patch review ends up > being a list > +of issues, not mentioning what is right and

Re: [MirageOS-devel] Formal vote on Unicore Proposal (deadline Frid, Oct 6th)

>>> On 29.09.17 at 14:07, wrote: > I propose to tally the votes by Friday the 6th of October. You can reply via > +1: for proposal > -1: against proposal > in public or private. +1 ___ MirageOS-devel mailing list

Re: [MirageOS-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

>>> On 12.08.16 at 01:13, wrote: > +### Lazy Consensus {#lazyconsensus} > + > +Lazy Consensus is a useful technique to make decisions for specific > proposals > +which are not covered by the Review Then Commit Policy or do not require a > more > +formal decison (see