Date: Sun, 13 Apr 2014 19:52:35 +0200 From: Matthew Rezny <matthew@reztek.cz> To: freebsd-ports@freebsd.org Cc: marino@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <1521997.Va510XRLDQ@desktop.reztek> In-Reply-To: <534AB84F.80203@marino.st> References: <2318877.ATaMhzlr5B@desktop.reztek> <2340470.BGPyZMtLr7@desktop.reztek> <534AB84F.80203@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 13 April 2014 18:16:15 John Marino wrote: > 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. > There are two different aspects that are being conflated. Some ports have a maintainer, but are marked for deprecation because upstream has not made changes in substantial time. That is what I was referring to here (example: cpupowerd). Other ports don't have a maintainer, and have little to no upstream activity as they are essentially done. and since they continue to build fine the only need for maintenance is to deal with changes to the ports infrastructure, which can be done by any ports commiter. > > 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. > No, that is not what I said, but perhaps I need to state it more clearly. There are other areas where I can contribute. I do not have infinite time. If I look at all areas where I can be useful, and then sort those by number of other people who could do the same, ports is not at the top if the heap. In fact, there are other people who can be more effective dealing with ports than I, people who have more experience/more willingness to deal with the mess that is autotools for example. I have more interest and competency in dealing with the core and thus that is where I choose to allocate the little time I have. This is a matter of efficiency. Of course, I realize that the base OS serves little use if there is no software to run on it, and some ports I need/want are neglected, so I must put some time towards this area as well. The more efficiently I can use that time, the better. > > 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. If there was a form to fill out to request ports commit access, I'd have doe that instead of filing PRs and waiting. > 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. > I know that and I'm volunteering to do that to save some of these, if I can indeed do so. As is evident, simply having a maintainer does not keep the port off the chopping block. > [snip a huge tl;dr (sorry)] > Sorry to hear about your ADD... > > 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. > \ I'm perfectly willing so long as I know it will actually be effective. If I take maintainership and end up waiting for patches to be commited while the port remains in a non-ideal state, I will be displeased and motivation to be involved in ports will decrease. If I find a port deprecated after taking maintainership, well, expect civility to take a hiatus. > > > 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. > On one hand, I agree that it's not responsible of the maintainer to let a port languish. On the other hand, it is effectively punishing the users for the maintainers lack of responsibility to deprecate the port. Unfortunately, I have seen more than one port loose it's maintainer over staging in the past few months. Essentially, the maintainer was fine doing updates, but when the rules of the game change, i.e. staging becomes mandatory, then they just say "I don't have the time for this anymore, someone else can take it" and walk away. > >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. > Actually, I have been paying attention. I can't watch every single port obviously, but I have seen the messages from portmgr stating it is open season, any committer can stagify ports without waiting for maintainer approval. That's great, but we are still at only 80% completion. Non- committers who wish to stagify a port are limited to submitting a patch, either as a PR or direct to the maintainer, either of which means they are then waiting on the maintainer to do something about it. > 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'm not sure where you got 96%. The 4% figure I stated is the portion of non- staged ports that are up on the chopping block this round, assuming all 221 ports in this round are non-staged. The downside is loss of useful ports. Not all ports that lack maintenance are crap. Everyone has a different definition of crap. If we consider deprecation to be flagging a port as crap, that crap flag needs to be more clearly conveyed to the userbase so it can be contested in a timely manner. I have watched these messages go by with little discussion under the assumption that the ports mentioned within were all BROKEN, FORBIDDEN, etc. It was quite surprising when I decided to look this time around and saw that the vast majority have no build problems and some even have maintainers. I regret having ignored the list in the past and that 2000 in 15 months figure is a bit disturbing to say the least. > > 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. > You don't think it's absurd to whack 20% of the ports tree right now? Wow > >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. ;) > apparently not entirely... > > 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 That's news to me, and probably many other users as well. End of April is rather close and I've not seen any mention of this deadline, neither on the website nor in the quarterly status reports, Both would be reasonable places to make a general call for volunteers to take maintainership of ports in need of care. Including figures on how many ports this is would be helpful to ensure the userbase understands this is not a small issue affecting just a few old ports.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1521997.Va510XRLDQ>