On 08.07.2024 09:00, Kelly Choi wrote:
> Hi all,
>
> As you are aware, George Dunlap has recently stepped down from the Xen
> Project as a committer, but he was also a part of the Code of Conduct team.
>
> As a result, Stefano will be the only member remaining on the CoC team. @Roger
> Pau Monne
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
>>>
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 lo
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
On 19.12.2019 11:03, Lars Kurth wrote:
>
>
>> 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 Lar
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 typicall
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 d
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,
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
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 co
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
>>>
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
___
MirageOS-dev
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: bracket
On 26.09.2019 21:39, Lars Kurth wrote:
> +### Express appreciation
> +As the nature of code review to find bugs and possible issues, it is very
> easy for
> +reviewers to get into a mode of operation where the patch review ends up
> being a list
> +of issues, not mentioning what is right and well
>>> 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
MirageOS-devel@lists.xenproject.org
ht
>>> On 12.08.16 at 14:53, wrote:
> On 12/08/2016 13:41, "Jan Beulich" wrote:
>>>>> On 12.08.16 at 01:13, wrote:
>>> +### Lazy Consensus {#lazyconsensus}
>>> +
>>> +Lazy Consensus is a useful technique to make decisions for spec
>>> 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 below). Lazy Consensus is e
17 matches
Mail list logo