Date: Sun, 13 Apr 2014 18:16:15 +0200 From: John Marino <freebsd.contact@marino.st> To: Matthew Rezny <matthew@reztek.cz>, freebsd-ports@freebsd.org Cc: marino@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <534AB84F.80203@marino.st> In-Reply-To: <2340470.BGPyZMtLr7@desktop.reztek> References: <2318877.ATaMhzlr5B@desktop.reztek> <534A3AC0.6060201@marino.st> <2340470.BGPyZMtLr7@desktop.reztek>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?534AB84F.80203>