On Fri, Jan 20, 2023 at 10:17 AM Max Kellermann <max+...@blarg.de> wrote:
> On 2023/01/20 10:53, Jakub Zelenka <bu...@php.net> wrote: > > > As it was said, this is problematic for bug fixes when merging up > > and it's extra hurdle for maintainers - read this will slow down the > > development. > > Can I do anything to help with those merges? > > 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. Then devs more likely remember what actually changed between releases and will be more careful when merging up. > > Also this is not something I would like to see in a minor version bump > even > > though we can break ABI in that version but in general we try to > introduce > > as little changes as possible for extensions. If anything it should at > > least wait for the next major version bump when extension devs expect > more > > work to be done. > > What about: let's branch PHP 8.3 out, and declare master will become > 9.0. (Or create a new branch for 9.0 and let 8.3 stay in master; > branches names doesn't matter, only the idea matters.) > > I volunteer to do regular (daily?) merges from the 8.3 branch to the > 9.0 branch, and fix all the problems that may occur. > > 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. Might be just easier to propose it before the actual major verison. 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 think comments are more useful in the actual header to explain > > what it is for which can be done in a few lines. It can be more > > detailed and doesn't need to be repeated... > > I agree with that part. More documentation for headers is useful. > > As I said in another reply, I feel those comments are only really > useful for those large and obscure catch-all headers such as > "zend_types.h". Check my "zend_result.h" commit - it makes lots of my > comments disappear, because suddenly the #include directive becomes > self-explaining. > I think if people are not sure what it does, they should just open the header and get explanation there so it should not be useful anywhere. > > > - some of the removed headers from libc should be kept as there's > > just a small benefit in removing them (e.g. errno.h) > > There is a benefit in removing them; improved compile times and > reduced namespace pollution (which is a theoretical benefit which is > probably not valued by all). > > But the benefit of keeping it is only source compatibility with buggy > extensions. > > And source compatibility with buggy extensions can be had by moving > those #include directives to "php_compat.h", with a way for "good" > extensions to opt out of the bloat. > > If you believe source compatibility even with "bad" extensions is > utterly important, I'll consider that in my submissions, and will > consider all build breakages as regressions that need to be fixed in > PHP (e.g. php_compat.h). I don't have a real opinion on that, I'll > accept whatever you decide and will help implement it. > > I think it should be at least included with "php.h" to reduce the impact on SAPI's and extensions. Regards Jakub
