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 since that code is now obviously of some importance to reviewer
Alex.
Amos
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
