Update for Nettle 4.0 base64 API

[yadij]

libnettle v4.0 and later will produce an error if the dst_length
parameter does not contain the size of dst buffer.

Earlier libnettle ignored the dst_length value as a write-only
parameter.

[yadij]

@rousskov as we have discussed before: simply wanting to review is not a good reason to block a PR. Please at least estimate deadline of when the blocking review should take place.

[rousskov]

as we have discussed before: simply wanting to review is not a good reason to block a PR. Please at least estimate deadline of when the blocking review should take place.

As we have discussed, you do not have the authority to decide what blocking reasons are good, and there is currently no agreement or consensus on blocking reasons classification or validation. My work has been (IMO incorrectly) blocked for more than a year, creating a long backlog and causing serious overheads, but I honor your right to block PRs and remain open to cooperating towards developing that consensus.

This PR is buggy and should not be merged until my concerns are addressed. I left a few change requests to facilitate progress but making the corresponding changes is not sufficient to address my concerns. I plan to come back to this PR after the backlog is cleared.

[yadij]

as we have discussed before: simply wanting to review is not a good reason to block a PR. Please at least estimate deadline of when the blocking review should take place.

As we have discussed, you do not have the authority to decide what blocking reasons are good,

a) your claim to higher authority is invalid.
b) assertion that anyone needs authority to make a statement is invalid.
c) there is/was no such thing as a "reason" existing at the time I made the statement.
d) I have made no such decision as claimed

and there is currently no agreement or consensus on blocking reasons classification or validation.

Please do not twist words to assign meanings that do not apply.

My work has been (IMO incorrectly) blocked for more than a year, creating a long backlog and causing serious overheads, but I honor your right to block PRs and remain open to cooperating towards developing that consensus.

FTR: Every block I have placed has been with a stated reason or request. You disagreeing with me does not make my input cease to exist.

That is a far cry from your action of simply blocking with no comment.

This PR is buggy and should not be merged until my concerns are addressed.

I see one "we should" opinion, and a "please do not" opinion. No bugs.

[rousskov]

Amos: as we have discussed before: simply wanting to review is not a good reason to block a PR. Please at least estimate deadline of when the blocking review should take place.

Alex: As we have discussed, you do not have the authority to decide what blocking reasons are good,

Amos: a) your claim to higher authority is invalid.

My response does not contain a claim to higher authority. Lack of authority does not imply the existence of a higher authority. In this discussion context, nobody has the authority to decide what blocking reasons are "good". Project rules do not grant that authority to anybody.

b) assertion that anyone needs authority to make a statement is invalid.

My response does not assert that "making a statement" requires authority. Acting on behalf of the Project (e.g., deciding what negative votes can be overruled or merging a PR) requires authority. Sharing personal opinions does not.

c) there is/was no such thing as a "reason" existing at the time I made the statement.

Your statement said "simply wanting to review is not a good reason". My response discussed that statement (about a reason).

d) I have made no such decision as claimed

You made a statement that classified "simply wanting to review" as "not a good reason". My response discussed that statement. IMHO, it is fair to say that you have decided to classify "simply wanting to review" as "not a good reason".

Recently, my negative votes and review requests were explicitly dismissed using similar "your vote/request is not good/valid" logic (and often with bad consequences for the Project). I felt I should respond to that statement in hope to prevent another disaster.

Alex: and there is currently no agreement or consensus on blocking reasons classification or validation.

Amos: Please do not twist words to assign meanings that do not apply.

FWIW, I see no word-twisting or inapplicable meanings here. I see a simple/direct statement describing the current lack of agreement or consensus on matters relevant to this discussion.

[kinkie]

Bringing back the conversation to the code.
There seems to be no outstanding request for changes.
What is needed to make this PR mergeable?

[yadij]

Bringing back the conversation to the code. There seems to be no outstanding request for changes. What is needed to make this PR mergeable?

PR bots: "Waiting for status to be reported — waiting for requested reviews"

[rousskov]

Alex: This PR is buggy and should not be merged until my concerns are addressed. I left a few change requests to facilitate progress but making the corresponding changes is not sufficient to address my concerns. I plan to come back to this PR after the backlog is cleared.

Francesco: What is needed to make this PR mergeable?

In short, bug fixes and my non-negative review (at least).

[yadij]

Alex: This PR is buggy and should not be merged until my concerns are addressed. I left a few change requests to facilitate progress but making the corresponding changes is not sufficient to address my concerns.

In other words; "change A, B, and also C (I wont tell you what C is, just pretend it is serious scary/bad), or else".

I plan to come back to this PR after the backlog is cleared.

Blackmail by any other name is still manipulative. The backlog for all of us should be much shorter if you would stick to technical issues instead of requiring "we should" opinions be "fixed".

FTR, right now the "backlog" (as seen by github) starts in 2017 with PR #55. Also waiting on @rousskov to accept authors coding decisions, fancy that.

Francesco: What is needed to make this PR mergeable?

In short, bug fixes and my non-negative review (at least).

Or rather: blocked until the attempted blackmail is successful, or reviewer changes their mind.

[kinkie]

I plan to come back to this PR after the backlog is cleared.

Blackmail by any other name is still manipulative. The backlog for all of us should be much shorter if you would stick to technical issues instead of requiring "we should" opinions be "fixed".
FTR, right now the "backlog" (as seen by github) starts in 2017 with PR #55. Also waiting on @rousskov to accept authors coding decisions, fancy that.

We all have PRs waiting for reviews. Let's focus on getting them merged, please. I agree we can do a better job at signaling which changes are required and which are suggestions for improvements; unfortunately Github is a bit blunt an instrument for that without some convention

Francesco: What is needed to make this PR mergeable?

In short, bug fixes and my non-negative review (at least).

The non-negative review is quite obvious. I was wondering what the bug fixes are - I checked the code and there is no outstanding comment to that effect. I checked resolved comments, no luck either. What did I miss?

[rousskov]

Amos: right now the "backlog" (as seen by github) starts in 2017 with PR #55. Also waiting on @rousskov to accept authors coding decisions, fancy that.

In this discussion context, I do not consider PRs that received prompt reviews but were awaiting author action for years a part of a backlog.

Francesco: We all have PRs waiting for reviews. Let's focus on getting them merged, please.

I have been focusing on that for more than 20 years -- writing high-quality code, posting prompt high-quality reviews, cooperating on resolving change requests, and absorbing personal attacks. This focus has not produced reasonable/acceptable results for the past 10+ years. The outcome hurts the Squid Project (and me personally) too much. Something has to change.

Francesco: What is needed to make this PR mergeable?

Alex: In short, bug fixes and my non-negative review (at least).

Francesco: The non-negative review is quite obvious. I was wondering what the bug fixes are - I checked the code and there is no outstanding comment to that effect. I checked resolved comments, no luck either. What did I miss?

The answer depends on what you were looking for. For example, if you were looking to replicate some of my PR experiences, you missed months of author begging for a review (after promptly addressing all change requests) and waiting for many months for the next review iteration (that would not be focused on getting the PR merged). And if you were looking for a list of bugs to address next, then I have not written those change requests yet. I also have not reviewed recent PR changes that look quite substantial/complex.

I understand that you would like me to continue doing what I have been doing all these years -- writing prompt high-quality reviews that identify all known bugs (among other things). Unfortunately, that approach has stopped working long time ago. I am pretty sure that simply continuing as if nothing happened is counter-productive. As you know, I am open to discussing what we can do to fix the current Project state.