On 12/26/21 8:36 PM, Amos Jeffries wrote: > On 27/12/21 10:11, Alex Rousskov wrote: >> On 12/26/21 10:30 AM, Francesco Chemolli wrote: >>> On Sun, Dec 5, 2021 at 10:05 PM Alex Rousskov wrote: >>>> If we manage to and agree on what platforms to "support" and >>>> on removing code dedicated to unsupported platforms, great! If >>>> we fail, I would like to propose an alternative scheme for the >>>> removal of platform-specific (or any other) code from the >>>> official master branch: >>>> >>>> A PR dedicated to code removal can be merged if it satisfies >>>> the following criteria: >>>> >>>> 1. Two positive votes from core developers. 2. No negative >>>> votes. 3. Voting lasted for 30+ calendar days. 4. The removal >>>> PR is announced in a PR-dedicated squid-users post. This >>>> announcement resets the 30+ day timer.
>>> How about instead something along the lines of: >>> 1. announce on squid-users about intent to remove support for a platform >>> 2. wait for objections for 15 days >>> 3. PR following standard merge procedure >> My proposal is trying to solve the specific problem that recent PRs >> (attempting to remove some code) have faced: The reviewer asked _why_ we >> are removing code, and the author closed the PR instead of developing >> consensus regarding the correct answer to that question[1]. My proposal >> establishes a special track for code removal PRs so that they do not >> have to answer the (otherwise standard) "why" question. > [1] is about removal of a trivial piece of code that has no harm leaving > in place. > > As I stated in followup what I regard as reasonable justification *was* > given up front. If that was not enough for agreement to merge it was not > worth the jumping through hoops in the first place. Let alone creating a > whole new bureaucratic policy and management process. > > As I said in other discussions, we already have a deprecation+removal > process that works fine and matches the industry standard practices when > a code change is even suspected to matter to anyone at all. That process > gives far more than just 30 days to inform any interested community > members and does not limit the notification channels. > > If anyone picks up the code removal in [1] again they should follow that > process I do not think they should. IMO, that (poorly working) deprecation+removal process should not be used for explicit OSF/1 support removal (among other things). They should use the regular PR review process (if we do not come up with something better by then). > since that code is now obviously of some importance to reviewer Alex. FWIW, I still[2] support removal of explicit OSF/1 support. The reason we had this discussion is not some special importance of that explicit OSF/1 support code. The goal is to lower the overhead of future PRs similar to the one you closed _because_ that overhead was too high. Hope this clarifies, Alex. [1] https://github.com/squid-cache/squid/pull/942#issuecomment-986208860 [2] https://github.com/squid-cache/squid/pull/942#issuecomment-986055422 _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
