FreeBSD ports which are currently scheduled for deletion

[John Marino]

On 4/13/2014 17:46, Matthew Rezny wrote:
>>> On this list I see cfv, which I've used for years, marked just because
>>> it's
>>> not maintained. It works great, it needs no changes. You want someone to
>>> bloat it with a useless non-feature to prove people still use it? I see
>>> there's a few other sfv checkers in ports tree, but then I have to go
>>> test all those, pick a suitable replacement, alter any scripts that call
>>> cfv to call the replacement, etc. Quickly looking at the options, all the
>>> others are less functional (two only do SFV, one does PAR, but not all
>>> the other formats cfv supports) and one of them is a GUI tool so useless
>>> for scripted invocation.

No, that's not what "maintenance" means.  Just building and apparently
working doesn't mean it requires no maintainer either.
MAINTAINER=ports at FreeBSD.org basically means it has nothing protecting
it from removal -- it means it's unmaintained by the definition here.


> Ok, if you want to get personal, then I'll pull out the stops. I don't mind 
> cracking skulls if that's what it takes...
> 
> I'm not officially a maintainer on any ports for a few reasons. I have other 
> areas where I consider spending my time more valuable, but if I have to waste 
> it on port maintenance, I'll try to do so in the most efficient way. 

Well, you basically said you're more important than anybody that
regularly reads this list, so good luck with that tact.

> Unless I 
> can directly commit changes to ports I maintain, then having my name 
> emblazoned on the port makes zero difference in terms of what I can do. I 
> already can submit patches as PRs and, more often than not, watch them linger 
> without action. I've experimented with directly mailing patches to maintainers 
> rather than adding one more PR to the database, believing that maybe that 
> would speed the process because it's one less step to fix/update the port if 
> there's not a PR to close (which might also be using someone else's time in 
> directing the PR to the maintainer). Regardless of the approach, it is often 
> slow to get a reaction if any. It's not my goal to be a maintainer of random 
> ports, but if that's what it takes to keep them from being deleted, fine. Just 
> give me the ability to actually maintain them.

So you should become a committer.
But no, it putting your name on a port stays the execution of the port
assuming you provide the patches to properly stage it first, so it's no
a vanity plate.  It serves a purpose -- most importantly it keeps it
away from the chopping block as long as you are a responsible maintainer.

[snip a huge tl;dr (sorry)]

> In summary, if you want me to maintain some ports, then lower the barrier to 
> entry and don't make me waste my time justifying the existence of ports I use 
> or maintaining local patches to keep the zombies alive after they've been 
> deleted without sufficiently informing the userbase. In just the time wasted on 
> this thread, I could have fixed more than one of these ports.

Try submitting the patches, including staging and assuming
maintainership (and then honestly be the maintainer).  That will be more
successful I think.
\
> Regarding staging specifically, I mentioned that as the most recent sweeping 
> infrastructure change. I understand the benefit of staging and wish it had been 
> done a long time ago. The point I was trying to make is that it is not yet 
> accepted and there are plenty of people who see it as one more hassle to 
> maintainership, or one more thing they need to work around to just keep stuff 
> working the way it has been for them. 

It is accepted by the ports committers.  Any port maintainer that
doesn't "accept" this may get lucky and have the port staged for him/her
(this happens a lot on easy-to-stage ports) or he may find that port
deprecated.  Staging is not an opt-in feature so as harsh as it is to
say, it's not up to these maintainers and realistically if they can't
make the adjustment they probably aren't qualified to be the maintainer
anyway.

>Those who were responsible for 
> implementing it should have expected that sort of response and should be 
> prepared to take some of the burden. Just passing the buck risks driving some 
> maintainers away if it looks like it's more effort than it's worth. Marking 
> ports for deletion just because they aren't stagified yet is even worse as it 
> greatly reduces the chance of anyone stepping up to maintain it. 

This indicates that you haven't been paying attention.  As you note
below, 20000 ports have been staged.  Do you think they've been staged
by the non-committers?  Most have been staged by committers on ports
they don't "own".  As you might expect, it takes a few months to go
through the entire tree and it's going extremely fast; much faster than
I thought realistic.  So they are holding the burden that you think they
should hold.

As was previously said, if 96% of the deprecated ports are deleted and
nobody says a damn thing, then great. on the 4% saved, they got fixed.
also great.  where's the downside?   It's not a goal to have the most
ports possible; something like 5000 ports have been pruned in the last 4
years, and probably close to 2000 ports alone in the last 15 months.
when the tree is 25k big, don't be surprised if not many people try to
save the crap.

> 
> I had planned to close by playing devil's advocate, listing all ports marked 
> NO_STAGE and calling for their immediate deprecation. However, that list is so 
> long that it would be truly absurd. 

Actually, not that absurd.  It's been threatened and it could happen.

>It would help my point that simply lacking 
> staging is an absurd excuse to deprecate a port, but the list is so long that 
> it would substantially increase the risk the rest of the message goes unread. 

too late.  ;)

> Current count in my local ports tree is 4983 ports are NO_STAGE. The total 
> number of ports is listed at 24387 at the moment, so that would be >20% of all 
> ports that should be immediately deprecated if we are to take a hard stance on 
> requiring staging. The 221 ports listed in the original message only represent 
> 4% of the problem ports, or <1% of total ports. It hardly makes a difference in 
> the grand scheme of things. Keeping these ports is worthwhile if you consider 
> the cost of doing so (nothing) against the cost of the potential ill-will 
> created by ignoring the userbase and deprecating/deleting for questionable 
> reasons ports that are still in use.

The deadline for completing staging is end of April.  It will be
interesting to see what happens.  Personally I think the ports
maintained by @freebsd.org that are not staged should be deprecated
first.  There are no excuses for that.

John