Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119506
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_5846a7be9e5294da563b44ebcb138f48"
Date: Thu, 09 Feb 2023 14:49:03 +0100
To: internals@lists.php.net
Message-ID: <a999a98954348cc4b36da3d75d8b987fc35eb17d2112cab8e5259cbbca4dce4f@mahalux.com>
Subject: Re: [PHP-DEV] How to deal with bugs in vendored libraries?
From: vorismi3@fjfi.cvut.cz (=?UTF-8?Q?Michael_Vo=C5=99=C3=AD=C5=A1ek_-_=C4=8CVUT_FJFI?=)

--=_5846a7be9e5294da563b44ebcb138f48
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8; format=flowed

One good way to maintain some quality standard is to enforce it thru CI
:) 

This also applies to https://github.com/php/php-src/pull/10549/files and
https://github.com/php/php-src/pull/10531/files for example, such
problems should fail the CI and enforce the contributors to fix the code
before the changes are merged. 

With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

On 9 Feb 2023 14:14, Max Kellermann wrote:

> On 2023/02/09 13:37, Rowan Tommins <rowan.collins@gmail.com> wrote: 
> 
>> Firstly, let's try to keep this discussion civil, and assume good faith on
>> both sides. Parts of your e-mail read like accusations of bad behaviour,
>> rather than genuinely trying to understand what happened, and how we can
>> collectively avoid it happening in future.
> 
> While I do have an opinion on whether I consider Derick Rethan's
> behavior bad (yes, I do), that's not the point here.  I don't know how
> to proceed after my PR thread was locked - that's an unequivocal sign
> of refusal to discuss the issue.  The issue still exists, and I'm here
> for your advice on how to resolve this.  I'm desperate.
> 
>> Secondly, note that Derick Rethans is the maintainer of both timelib and
>> the ext/date extension in php-src. So while we can discuss the hypothetical
>> question of how to handle a disagreement between php-src and upstream
>> library maintainers, it wouldn't apply in this case anyway, because it
>> would require Derick to disagree with himself.
> 
> That depends.  Did the PHP project decide to go C99 starting with
> version 8?  What does that mean for maintainers - can they decide to
> make code changes that are not compliant with that decision?
> 
> That is a honest question.  I don't know how PHP works.
> 
> That's why I asked whether "secret" reverts without discussion are
> considered good behavior.  Maybe you believe maintainers should do
> that - but that would be surprising for me.
> 
>> Thirdly, it's not clear to me which of the following statements is true of
>> this change, and it might help the conversation to clarify more precisely:
>> a) The code you removed *violates* the C99 spec?
> 
> This.  The code in question declares typedefs that are reserved words
> in the C99 spec section 7.26.8; not just reserved, they conflict with
> actual typedefs from <stdint.h>.
> 
>> b) The code you removed is *guaranteed to be pointless* under the C99 spec
>> (but does not violate it)?
> 
> No.  It is not pointless.  Those declarations occupy reserved words,
> and that is not allowed.
> 
>> c) The code you removed is *pointless in this particular case* because of a
>> combination of the C99 spec and other factors (but might be reasonable in
>> other circumstances)?
> 
> I don't understand this one, but it doesn't sound like it applies.
> 
> Max
--=_5846a7be9e5294da563b44ebcb138f48--