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.
>>>>>
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283266
>>>>>
>>>>> 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,
>
(sending again from a proper email client - *sigh*)
> 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
[0] e.g., https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276186
