Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122714 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 7890D1A009C for ; Thu, 21 Mar 2024 18:53:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1711047222; bh=aiMg+IbnJjrMvZ0alQH4X7fB3kRRwMCrto0TMsm1OIE=; h=Date:From:To:In-Reply-To:References:Subject:From; b=D/n+2LG57fM5sf6TXA9+UNwdq29og8kDirppU977BJeuqFtpyZvBgcYXYACnzLEMC 0dDRqKNsI/LFtgNHlypN4+N1mO6zUaY30Tmn5VZQo+LnVcaiy8Hx1QO4ppZ6FuijNp IE5yfx38wr8wqoIpl0++ylt00n+HeGE2vLylx1uDvjhFSVOqOR5jEbmq3Xa15DELhx 5D0ly42r6e9kWfHVA8wWpSydtfuNQpEr2ZfEqSVQzxgn89YtGOmsed7QWagq2csw6D 5fLBM4IoXxPEUKn5DfEi04c4g+K+NxtrhsrWrIXOxALZ0ucCbIfs+Q1Rwg7qSQYdGP bU5DAiRH0DkNg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8DB0118005F for ; Thu, 21 Mar 2024 18:53:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 21 Mar 2024 18:53:41 +0000 (UTC) Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-33e17342ea7so603531f8f.2 for ; Thu, 21 Mar 2024 11:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711047197; x=1711651997; darn=lists.php.net; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=+CyaRRZUkXdt6mEikL2iLGPCFZPaLHBQKTY07qbbapQ=; b=KiQGdOdK4DhHU+W4lFdMurjyJ+HaG/O9Gb8GpBLSfE0DcvdZx/skhBDSPcqL+Dzr3w dPu3mQcnDaJSo2R/XKZDw6Sxg6/7kAtx1+UBvZW6md+1Boty9mMLEDvAJUrvS+pEiG8C e5S7GLso/jjPUvsZMWM/EZe6ki/pHQ8t9XHC+3oZ7ymH1t7MNEZt5ShwZHDpfQGyZ9Il fxO2so7aIcxTDvMh1OTSAslkP8G2WbRcP29/5jz5Q9UPN11PddrMw8xaaMF9pqkgS761 p0Ye9a1HLHZUa5D/rw9EdQmfHqM9FDTGQHtbT4H8LoHi6gjsDMuc/lMny5YJRFPACPYe mmDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711047197; x=1711651997; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+CyaRRZUkXdt6mEikL2iLGPCFZPaLHBQKTY07qbbapQ=; b=b9bAwT+g/RkHH45GtINGzbk72zeGP7556jaDTvOsBwU8Cd7KNZOBtzDbzxzMCi2OJQ Dq2vZyhJQlBAn1DiUeK4AypkhBchCoTMZRkvJOL09N048VDinOH39Il/9UleJjOi+exv VU0mzmZIQHhguc/MfqPUA49xa+bSQVWxoAQMj1VuWVVySmFOuCpafr5LNTle6l9Fa4tK qgpJPlmKaqgXpGk7mpjzCjhYAvBr3JQ/FWNDKQIu/KV+zOpjGC87H/Dgny8/MYESywAK DKjkc4Ryv3wkGlT3iDZa4NTfY6Ktbcbnc8mnpZkQ5bYw41ZVGOha+a7xxLR8tQSpTFXc 68Hg== X-Gm-Message-State: AOJu0YywShqV/67NiTfosm/8IXHP7+99tfGPdqrRGGwQpuqa4SifU2VN Psqngbw/uzyc3R2Od2QOz1KzqEEwLDssAHKzwJSgJVC4hGm6Lw5Vxehqod79 X-Google-Smtp-Source: AGHT+IHCuugMR9Z6Kij7/QNMn+OWiirrAStEelEyqBs2eX3j9GyhcEzb+bH0xCDtEIaTG3fTTLKVtA== X-Received: by 2002:a05:6000:2c3:b0:341:a7dd:9e78 with SMTP id o3-20020a05600002c300b00341a7dd9e78mr38368wry.36.1711047197169; Thu, 21 Mar 2024 11:53:17 -0700 (PDT) Received: from [127.0.0.1] (as198747.daniil.it. [128.116.205.77]) by smtp.gmail.com with ESMTPSA id bw28-20020a0560001f9c00b00341b3b0d9e9sm122625wrb.19.2024.03.21.11.53.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Mar 2024 11:53:16 -0700 (PDT) Date: Thu, 21 Mar 2024 19:53:14 +0100 (GMT+01:00) To: internals@lists.php.net Message-ID: In-Reply-To: <04736cc6-0372-8228-7d2a-7e12453a8f0c@php.net> References: <04736cc6-0372-8228-7d2a-7e12453a8f0c@php.net> Subject: Re: [PHP-DEV] [RFC] Release cycle update, take #2 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10_226545465.1711047195024" X-Correlation-ID: From: daniil.gentili@gmail.com (Daniil Gentili) ------=_Part_10_226545465.1711047195024 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit >> I would like to propose a new process RFC for updates to PHP release >> cycle: >> >> https://wiki.php.net/rfc/release_cycle_update I would also like to propose an addition, allowing patch releases to be made outside of the normal release schedule if a major core feature is broken by a fix in the previous patch release. These out-of-schedule releases should only contain a clean revert of the fix that broke the major core feature. I believe the "major core feature" set should include at least the garbage collector and string functions, it may be extended if needed. I'm advocating for this change due to the fact that critical garbage collector bugs were introduced and released at least twice in the last year: - First with a GC patch that completely broke garbage collection causing segfaults if fibers are used (https://github.com/php/php-src/pull/9810) - And then with a GC patch that broke garbage collection causing segfaults when using weakmaps (https://github.com/php/php-src/pull/10932) Specifically regarding the first bug, the fix for it was actually delayed by 30 days, instead of 15 (the time left until the next release, when the fix PR was merged), as a security release was made the day after the fix was merged, delaying the entire release cycle by 30 days. I believe that bugs in major core features, introduced by fix PRs should be reverted ASAP, especially if they aren't noticed until a release, instead of breaking a core feature of the language for one month (or more if a security release delays the normal release cycle). Also in general, I find it wrong that security releases should delay the normal cycle. Regards, Daniil Gentili. ------=_Part_10_226545465.1711047195024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
>> I would like to propose a new process RFC for updates to PHP release
>> cycle:
>>
>> https://wiki.php.net/rfc/release_cycle_update

I would also like to propose an addition, allowing patch releases to be made outside of the normal release schedule if a major core feature is broken by a fix in the previous patch release.

These out-of-schedule releases should only contain a clean revert of the fix that broke the major core feature.

I believe the "major core feature" set should include at least the garbage collector and string functions, it may be extended if needed.

I'm advocating for this change due to the fact that critical garbage collector bugs were introduced and released at least twice in the last year:

- First with a GC patch that completely broke garbage collection causing segfaults if fibers are used (https://github.com/php/php-src/pull/9810)
- And then with a GC patch that broke garbage collection causing segfaults when using weakmaps (https://github.com/php/php-src/pull/10932)

Specifically regarding the first bug, the fix for it was actually delayed by 30 days, instead of 15 (the time left until the next release, when the fix PR was merged), as a security release was made the day after the fix was merged, delaying the entire release cycle by 30 days.

I believe that bugs in major core features, introduced by fix PRs should be reverted ASAP, especially if they aren't noticed until a release, instead of breaking a core feature of the language for one month (or more if a security release delays the normal release cycle).

Also in general, I find it wrong that security releases should delay the normal cycle.

Regards,
Daniil Gentili.
------=_Part_10_226545465.1711047195024--