On Fri, 20 Dec 2024 02:35:01 +0100
Daniel Engberg <daniel.engberg.li...@pyret.net> wrote:
> On 2024-12-20T02:06:46.000+01:00, Michael Gmelin <gre...@freebsd.org>
> wrote:
>
> >> 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:
> >>
> >> ...snip...
> >> 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
> >
> > [0] e.g., https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276186
>
> Hi,
>
> Unfortunately this seems to take a wrong turn as you appear to want to
> drive your narrative endlessly irregardless
I don't have a narrative, just honest feedback based on what I've seen.
> There's more to it than what you seem to aware of however if you want
> to discuss incidents further we can do this in another forum.
Assuming there are important facts that are not in the open, having
that deeper knowledge of the situation would certainly help.
Best
Michael
--
Michael Gmelin
