Re: Looking for testers for curl - PR 283266

Thu, 19 Dec 2024 17:07:26 -0800



On 20. Dec 2024, at 00:18, Daniel Engberg <daniel.engberg.li...@pyret.net> wrote:


On 2024-12-19T23:30:41.000+01:00, Michael Gmelin <gre...@freebsd.org> wrote:



On 19. Dec 2024, at 22:26, Daniel Engberg <daniel.engberg.li...@pyret.net> wrote:

On 2024-12-19T21:33:14.000+01:00, Michael Gmelin <gre...@freebsd.org> wrote:
On Thu, 19 Dec 2024 20:39:54 +0100
Daniel Engberg <daniel.engberg.li...@pyret.net> wrote:

  Hi,
 
 While this should be uneventful if possible please try PR 283266 and
 report back if you run into any issues and of course success stories
 too.
 
 
 Best regards,
 
 Daniel (diizzy@)
 
 
Prior to testing, one question: The bug indicates that the port
maintainer was not involved in these changes - is this true and has it
been resolved in the meantime?

Best
Michael

-- 
Michael Gmelin
Hi,

There has been no response from the maintainer regarding PRs about this port for over 2 weeks, see PR 283020

This PR was opened on 2024-11-28. You committed a patch mentioning it a week later, so it might very well look like you fixed the problem (which is what I thought at first when seeing it). Apparently that was a reference error (accidental, I assume).

and also the end at the first comment in PR 283266.

The end of the first comment in that PR reads “Cheers Max”.

PR 283266 has yet to reach maintainer timeout.

This PR is eight days old by now and it’s Christmas/Holiday season, so it certainly won’t hit maintainer timeout on Christmas Eve or the holiday week in general. I would say, acting in good faith, maintainer timeout should be delayed by at least one or two additional weeks on this one.

Lining up PRs preparing for a timeout and making a maintainer change part of that, strategically planing ahead to commit the very moment the right number of days has passed, doesn’t seem like an ingenious way of cooperating with your fellow project members to me.

Best
Michael
Hi,

Since you seem to intentionally misinterpret and not seem to be aware of policies.
I answered your question and if you read Porters Handbook it says the following, "If the maintainer does not respond to an update request after two weeks (excluding major public holidays),

We are in a period of major public holidays.

then that is considered a maintainer timeout, and the update can be made without explicit maintainer approval.". So no, there has been no involvement because the maintainer hasn't replied and it hasn't reached maintainer timeout.

Your primary reasoning to propose the change of maintainership was maintainer timeout.

There weren’t three consecutive ones and there was no period of three months without feedback (at least afaik). “There has be no response from the maintainer about PRs about this port for more than 2 weeks” is not enough to rationalize such drastic changes.


I also clarified the suggested maintainer change by

This would be a lot more credible if the takeover of maintainership wouldn’t be mixed with sweeping changes to how the port is built, which happen to include exactly those which the maintainer opposed.

"...which is why assigning it to a group is likely a better idea for some ports such as this one."

That depends on the group. I honestly don’t know who’s in desktop@ (I couldn’t figure it out googling for 60 seconds, so maybe there is a record somewhere and I’m too lazy). 

Having someone actually responsible sometimes works better than a group, unless that group provides sufficient transparency. I don’t see that sunpoet has failed us as the maintainer for this port and it doesn’t seem like you discussed it with them in a genuine way. So maybe that would be a first step, even if it means spending time and effort on that human interaction.

Besides that, as someone else already pointed out, desktop@ doesn’t seem like an obvious choice to me.

That's from the first comment in PR 283266. That is subject to change and not final because it's an open PR and up for reviewing.

The first comment is by Max. You probably mean the bug description written by yourself (yes, that’s nitpicking, but as this was coming from someone who cares a lot about detail, I took the liberty to take you literally).


So neither of your claims are valid, please read more carefully next time.

Beyond policies (which are there to give us guidelines to operate by), we are a group of individuals collaborating, so human interaction, acting in good faith and giving other collaborators the benefit of the doubt should come first. Which, for example, also means, not using maintainer timeout to deprecate ports, just because the maintainer didn’t manage to react within 1209600 seconds[0].

Likewise, I should assume you’re acting in good faith, but even if you mean well, following your emails about (sometimes minor) corrections on commits, especially on sunpoet’s, often written in a demanding and disrespectful tone, makes that hard and it creates an atmosphere in which one thinks twice about making a contribution or even open a bug report.

Regarding the issue at hand, I would suggest that, instead of trying to do this in a “let’s hope we reach maintainer timeout” style, you raise the topic of curl maintainership with portmgr and/or core and - given that it’s such an important/central piece of software - make your case why this transfer of maintainership to desktop@ is supposed to be a good idea.

Best
Michael





Reply via email to