Date: Sun, 13 Apr 2014 20:36:58 +0200 From: John Marino <freebsd.contact@marino.st> To: Matthew Rezny <matthew@reztek.cz>, freebsd-ports@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <534AD94A.2030105@marino.st> In-Reply-To: <1521997.Va510XRLDQ@desktop.reztek> References: <2318877.ATaMhzlr5B@desktop.reztek> <2340470.BGPyZMtLr7@desktop.reztek> <534AB84F.80203@marino.st> <1521997.Va510XRLDQ@desktop.reztek>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/13/2014 19:52, Matthew Rezny wrote: > 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). Er, cpupowerd is your example? It was deprecated by the maintainer! They are in the best position to judge when a port should be deprecated (yes, even more than a *random* user.) I could imagine you could find a better example, but look at the history to figure out if the maintainer was really active. I've found ports with listed maintainers where he didn't do squat (or even had a valid email account) for the better part of a decade. I do not believe ports with active maintainers were deprecated. >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. Okay, but I am a member of "any ports committer", and I don't like it that you expect me to maintain these ports. In fact, all of these ports that you think work despite being maintained probably had constant maintenance by "any ports committer" for years. So these are a burden and I object to the concept that ports@ means "maintained by everyone". There are even some committers that believe this, but for me ports@ means "maintained by nobody" and I will reject any responsibility thrust on me. I do maintain these ports occasionally, but only because I was in a good mood and I consider it a gift, not an obligation. I request from you that you don't consider it an obligation either. > >>> 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. okay, you said it better that time. :) >> 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. generally if you fill out enough good PRs you'll get approached about being a committer and somebody will have already volunteered to mentor. You can imagine a lot of good intentions that don't pan out so some sort of track record is a discriminating factor. In your defense, I know the PR backlog is huge, probably as a direct result of so much effort put into staging ATM. > >> [snip a huge tl;dr (sorry)] >> > Sorry to hear about your ADD... Notice that I'm the only one responding -- I have things to do as well that I really should be doing instead of this. I gave you what I could afford (and more). > >>> 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. Ports don't get chopped at expiration if they have pending PRs that fixes the issue. If it happens it's a mistake that will be quickly rectified. This "deprecation" slash-and-burn is a once in a decade event I think. It should be over when the staging is over. >>> 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. Then one of them should volunteer to maintain the port (seriously). > 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. Ok. Just a standard failure to agree to terms. People walk all the time for various reasons, so the requirement to stage isn't going to be dropped because of maintainer like that (I personally haven't seen that but I believe you that it happened). > 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. That was a big (welcome) shift in policy that was successful. You keep saying stuff like "only". 80% staging in this amount of time is an impressive accomplishment. The PRs will not be wasted. If there is a PR in the backlog on an unstaged port, it will be looked it, sooner rather than later. >> 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. >From Rees stating that he could drop 50 ports and only 3 get resurrected. So some effort is spent on those 6% to fix and resurrect and tons of effort was saved on the 47 that died. The valued ports survived and got fixed, the trash got thrown out, so win-win. > 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. If nobody steps up to maintain, it's not considered useful (e.g. it wasn't important enough to ANYBODY to save it). The issue is that you think it's zero effort to keep ports around and it is not. It's a burden and nobody is willing to shoulder that burden. bye-bye then. >>> 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 Deprecation doesn't mean wack. It also doesn't mean "1 week". It would probably be deprecated for several months. And marking it deprecated will get most of them fixed. So no, it's not absurd, it means "no more procrastination, time's up". > > 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. I have a feeling that deadline might get extended. Because it's not official, don't treat what I said as official. But as bdrewery said elsewhere, something official is coming down the pipe soon, at least for the committers. I was basically trying to convey that there is motive to finish staging as soon as can be done. you already have the figures (~4700 ports), but here's a dynamic list: http://people.freebsd.org/~bapt/notstaged.txt by the way, "call for volunteers" isn't the issue. You'd just get some jokers that would say, "hell, put my name there" and do nothing. In most cases, the port would need actual patches if it's marked for death (meaning it's not an easy fix, otherwise it would be fixed by a kind committer). John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?534AD94A.2030105>