This is the mail archive of the
mailing list for the glibc project.
Re: [PING] [PATCH] sys/ptrace.h: remove obsolete Linux PTRACE_SEIZE_DEVEL constant
On 08/09/2017 09:10 AM, Zack Weinberg wrote:
> On Wed, Aug 9, 2017 at 6:39 AM, Florian Weimer <email@example.com> wrote:
>> On 08/08/2017 09:07 PM, Carlos O'Donell wrote:
>>> On 08/08/2017 12:30 PM, Dmitry V. Levin wrote:
>>>> On Tue, Aug 08, 2017 at 09:20:17AM -0400, Carlos O'Donell wrote:
>>>>> On 08/07/2017 11:33 AM, Dmitry V. Levin wrote:
>>>>>> Looks like among those few who care about sys/ptrace.h nobody feels
>>>>>> experienced enough to review this change, so I'll go forward and commit it.
>>>>> Please tread carefully, and give the machine maintainer time to review, or
>>>>> directly TO: the machine maintainers and ask for review.
>>>>> Lack of a response does not mean you can assume consensus. Follow up with
>>>>> machine maintainers, even one ACK from a maintainer goes a long way to
>>>>> knowing there is support for your change.
>>>> JFYI, PTRACE_SEIZE_DEVEL was an architecture-independent constant.
>>> Agreed, but the patch still touches machine-specific headers.
>> I don't think our maintainer process confers exclusive code ownership,
>> quite the opposite actually. It's unblock-by-default for the
>> maintainer, not block-everyone-else.
>> I looked at Dmitry's changes, and they look good to me. Please
>> reconsider your opposition.
> I don't know Carlos's mind, but it seems likely to me that he didn't
> mean to issue a hard NAK, he just wanted the flood of "nobody reacted
> to this patch during the freeze so I'm going to take that as assent"
> check-ins to slow down. I'm'a send another message about that.
The maintainer process does not confer exclusive ownership, and if it
sounded like I was advocating for that, then that is not at all the
message I intended.
What I wanted to avoid was the impression that silence implied
consensus, and that caution should be taken when implying such
consensus for patches that touch multiple machines.
I want Dmitry to find *other* reviewers to look over the patch and
give cosensus over the changes.
I'm happy for Dmitry to commit them now that both you (Zack) and
Florian have looked at the patches and consider the changes OK.
Three developers is a good belt-and-suspenders peer review for
multiple-machine header changes.