Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119366 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 73642 invoked from network); 20 Jan 2023 11:15:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 Jan 2023 11:15:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9B23B180547 for ; Fri, 20 Jan 2023 03:15:08 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 138.201.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from swift.blarg.de (swift.blarg.de [138.201.185.127]) by php-smtp4.php.net (Postfix) with ESMTP for ; Fri, 20 Jan 2023 03:15:08 -0800 (PST) Received: from swift.blarg.de (swift.blarg.de [IPv6:2a01:4f8:c17:52a8::2]) (Authenticated sender: max) by swift.blarg.de (Postfix) with ESMTPSA id EBED641294; Fri, 20 Jan 2023 12:15:06 +0100 (CET) Date: Fri, 20 Jan 2023 12:15:05 +0100 To: Jakub Zelenka Cc: internals@lists.php.net Message-ID: References: <192ba7b6-dcf0-e2da-c99e-cbad40519e27@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [PHP-DEV] RFC: rules for #include directives From: max+php@blarg.de (Max Kellermann) On 2023/01/20 11:52, Jakub Zelenka wrote: > Reduce the diff to absolute minimum to prevent potential conflict. I think > it would be more acceptable if there was a plan that will get us there in > multiple releases rather than do one big bang change. My draft PR currently contains 104 very small commits, one for each library that I fixed. If you like some of them, it's easy for me to submit a new PR with that selection, and then you can merge them. I'll keep the rest rebased, for some day you decide to merge the rest. That's up to you. I don't know what kind of "plan" I need to have - I clean up what needs to be cleaned up, but first, we need to decide what "there" means in "get us there". > Well we don't even know when 9.0 will be tagged so this could span to years > which might be waste of your resources just for the sake of headers. A lot of work is already done, and I keep this branch rebased on master, which is just as much work as merging, no real difference. No time saved. On the other hand, having an official branch to become 9.0 or whatever version with my patches already in, others can chime in and help with the code cleanup. > That said I think it would be maybe more sensible what I mentioned > above and that's to split the work to multiple steps over the years. I don't know what you mean by that. Cleaning up a code base is incremental work; I have 104 of those splitted steps in my branch, and many more steps may follow. This will take years, or rather: will never be finished, because code can always be improved some more. Do you mean I should work more slowly? I should submit my patches more slowly? In smaller PRs? Wait more between PRs? Before I submitted my work, I was specifically asked to submit smaller PRs with fewer commits, which I did, and the first 4 small PRs were merged, with more waiting in my queue (until my effort was stopped by Dmitry's veto). > I think it should be at least included with "php.h" to reduce the impact on > SAPI's and extensions. OK, noted, I'll amend my PR branch to move omitted #includes to php.h/php_compat.h to retain source compatibility. Max