On 1/7/20 4:44 PM, Jan Beulich wrote:
> On 07.01.2020 17:17, George Dunlap wrote:
>> On 1/7/20 1:05 PM, Jan Beulich wrote:
>> 2. It must have either a an Acked-by from a maintainer, or a
>>Reviewed-by. This must come from someone other than the submitter.
>
> Better, but leaving ambiguous
On 07.01.2020 17:17, George Dunlap wrote:
> On 1/7/20 1:05 PM, Jan Beulich wrote:
>> On 07.01.2020 13:03, George Dunlap wrote:
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -104,7 +104,53 @@ Descriptions of section entries:
>>>xen-maintainers-
>>>
>>>
>>> -The meaning of nesting:
On 1/7/20 1:05 PM, Jan Beulich wrote:
> On 07.01.2020 13:03, George Dunlap wrote:
>> DISCUSSION
>>
>> This seems to be a change from people's understanding of the current
>> policy. Most people's understanding of the current policy seems to be:
>>
>> 1. In order to get a change to a given file
On 07.01.2020 13:03, George Dunlap wrote:
> DISCUSSION
>
> This seems to be a change from people's understanding of the current
> policy. Most people's understanding of the current policy seems to be:
>
> 1. In order to get a change to a given file committed, it must have
> an Ack or Review
On 1/7/20 12:03 PM, George Dunlap wrote:
> v2:
> - Modify "sufficient time" to "sufficient time and/or warning".
> - Add a comment explicitly stating that there are exceptions.
> - Move some of the alternate proposals into the changelog itself
Sorry, this should obviously have 'v2' in the
The "nesting" section in the MAINTAINERS file was not initially
intended to describe the check-in policy for patches, but only how
nesting worked; but since there was no check-in policy, it has been
acting as a de-facto policy.
One problem with this is that the policy is not complete: It doesn't
On 5/9/19 12:16 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH] MAINTAINERS: Add explicit check-in policy
> section"):
>> +Check-in policy
>> +===
>> +
>> +In order for a patch to be checked in, in general, several conditions
>> +must be met:
>
> I think it is very
>>> On 09.05.19 at 13:05, wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH] MAINTAINERS: Add explicit
> check-in policy section"):
>> On 5/8/19 12:59 PM, Juergen Gross wrote:
>> > 2. In the case the submitter is a maintainer of a modified file it mus
George Dunlap writes ("[PATCH] MAINTAINERS: Add explicit check-in policy
section"):
> + Check-in policy
> + ===
> +
> +In order for a patch to be checked in, in general, several conditions
> +must be met:
I think it is very helpful to write guidelines, but I am opposed to
George Dunlap writes ("Re: [Xen-devel] [PATCH] MAINTAINERS: Add explicit
check-in policy section"):
> On 5/8/19 12:59 PM, Juergen Gross wrote:
> > 2. In the case the submitter is a maintainer of a modified file it must
> > have an Ack or Review from either a "nest
On Wed, 8 May 2019, George Dunlap wrote:
> + Check-in policy
> + ===
> +
> +In order for a patch to be checked in, in general, several conditions
> +must be met:
> +
> +1. In order to get a change to a given file committed, it must have
> + the approval of at least one
>>> On 08.05.19 at 13:39, wrote:
> The "nesting" section in the MAINTAINERS file was not initially
> intended to describe the check-in policy for patches, but only how
> nesting worked; but since there was no check-in policy, it has been
> acting as a de-facto policy.
>
> One problem with this
On 5/8/19 12:59 PM, Juergen Gross wrote:
> What about variant 2b:
>
> 1. In order to get a change to a given file committed, it must have
> an Ack or Review from at least one maintainer of that file other than
> the submitter.
>
> 2. In the case the submitter is a maintainer of a modified file
On 08/05/2019 13:39, George Dunlap wrote:
> The "nesting" section in the MAINTAINERS file was not initially
> intended to describe the check-in policy for patches, but only how
> nesting worked; but since there was no check-in policy, it has been
> acting as a de-facto policy.
>
> One problem
The "nesting" section in the MAINTAINERS file was not initially
intended to describe the check-in policy for patches, but only how
nesting worked; but since there was no check-in policy, it has been
acting as a de-facto policy.
One problem with this is that the policy is not complete: It doesn't
15 matches
Mail list logo
