On Mon, 26 Oct 2026 19:43:16 +0100 Daniel Engberg <[email protected]> wrote:
> On 2026-10-26 19:40, Chris wrote: > > On 2026-10-26 11:09, Daniel Engberg wrote: > >> On 2026-10-26 18:51, Chris wrote: > >>> On 2026-10-26 08:32, Mark Millard wrote: > >>>> On 10/26/26 07:44, Lexi Winter wrote: > >>>>> Dan Langille wrote in <2936739a-9bff-4fd5-9cb6- > >>>>> [email protected]>: > >>>>>> You are short-cutting the process. First, mark the port broken after > >>>>>> one month of it being actually broken. Did you do that? No. A few > >>>>>> months later, mark it deprecated. Did you do that? No. With those > >>>>>> steps taken, the port will be garbage collected by the usual process. > >>>>>> No need for you to delete it like you did. > >>>>> > >>>>> it's been broken for five months. who cares? if the answer is > >>>>> anything > >>>>> other than "no one", the person who cares can resurrect the port and > >>>>> maintain it. > >>>> > >>>> (Not that I care about the specific port but I'm curious about the > >>>> process:) > >>>> > >>>> Can a potential maintainer that is not a committer reinstate the > >>>> port on > >>>> their own? > >>>> > >>>> If not, it would seem that the thing missing for reinstatement would be > >>>> someone requesting the reinstatement that also indicates they want > >>>> to be > >>>> the maintainer. > >>>> > >>>> If it does not already have such, I wonder if the policy should have > >>>> some words about that for long-broken ports that are deleted. > >>> > >>> There's nothing to stop anyone whom uses the port from claiming > >>> MAINTAINER > >>> and submitting a patch to fix it. They needn't already be a maintainer. > >>> The only problem I see here is that is that the standard procedure > >>> wasn't > >>> followed; Mark port broken --> give it a expires/depreciation date. If > >>> nobody steps up, remove it on depreciation date. > >>> > >>> @anyone whom wants to keep this port; > >>> grab and reverse the commit patch. Apply it to a fresh ports tree. > >>> Add and or > >>> modify patches as required to fix the port. Add yourself as > >>> MAINTAINER. Generate > >>> a patch. Submit it to Bugzilla. Done. > >>> > >>> @daniel > >>> You short-circuited the process. You've been doing this long enough > >>> to know > >>> better. > >>> > >>>> > >>>>> > >>>>> otherwise, nothing is lost by deleting a broken port. > >>>>> > >>>>> we should not let arbitrary rules stand in the way of improving the > >>>>> ports tree, especially considering the state of ports. > >>> > >>> --Chris > >> Read up, you're wrong and a maintainer actually needs to (as the title > >> implies) > >> maintain. Additionally it doesn't make any sense to add software > >> that's about one > >> year behind and unsupported upstream so it needs to be updated too. > > > > I performed due diligence. While the (currently listed) maintainer > > failed to keep > > the port functional. You failed to mark it broken, adding an expires > > date. In the end > > it all seems the same. But having an expires date expresses the urgency > > any would-be > > maintainer may need to get "off the fence" and get to work producing a > > patch to make > > this a valid port again. > > As to unsupported; While the gtk/gnome version is unsupported. Upstream > > has a QT > > version that *is* supported. > > > > On an aside; you'll be happy to know I'll be culling my ports list this > > week of many > > ports I now consider unworthy of maintaining. As they're too niche to be > > of any real value. :) > > > >> > >> Best regards, > >> Daniel > > > > --Chris > > Try again, > https://cgit.freebsd.org/ports/commit/?id=d0528bbc1318371bfb9f81b3c1a4e56eeaab6c60 > > Best regards, > Daniel Thanks! It should be the right and polite way for deletion. But fortunately, joneum@ upgraded it with related resurrected ones. https://cgit.freebsd.org/ports/commit/?id=ec0f0d269bc36f04fb0c1409ca38d3e6bcc6d4f3 Regards. -- Tomoaki AOKI <[email protected]>
