[squid-dev] What os/cpu platforms do we want to target as a project?

[Alex Rousskov]

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