Date: Sat, 24 May 2014 16:04:54 +0200 From: Matthew Rezny <matthew@reztek.cz> To: marino@freebsd.org Cc: freebsd-ports@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <2827292.qM76QHi0yk@workstation.reztek> In-Reply-To: <534AD94A.2030105@marino.st> References: <2318877.ATaMhzlr5B@desktop.reztek> <1521997.Va510XRLDQ@desktop.reztek> <534AD94A.2030105@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
After a break for over a month due to connectivity issues and other RL crap, a followup appears... On Sunday 13 April 2014 20:36:58 John Marino wrote: > 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.) > The long list of deprecations did not make it clear who deemed any of those as deprecated. If it was indeed the maintainer, that is a shame. If the maintainer doesn't have a use for it, he should put it up for adoption. To deprecate and delete just because he doesn't see a use for it personally is ridiculous. Everyone else using it is probably taken by surprise. Asserting the maintainer is in the best position, over all other users, to decide when it should be deprecated, is patently retarded. > 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. > If you don't like it, then don't do it, but don't stand in the way of anyone else that does. Also, cut the crap. If maintainer is ports@, then what that literally means is the ports community as a whole is maintaining those ports. If they are not maintained by anyone, then the maintainer should be NULL. Using ports@ to mean NULL is extremely misleading. As long as the ports community continues to put ports@, I and others will continue to expect the ports committers to take some responsibility for those ports they have branded with their address. If you object to that, change the maintainer line. > >>> 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. :) > Which requires more words, which risks it not being read. You've already expressed your aversion to reading. > >> 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. > Catch 22. Why am I going to put forth the effort to have my work largely ignored? The claim that there is a risk of someone with good intentions not following through is absurd. If someone is given the ability to fix the port and doesn't use that ability, no harm was done. The greater risk is someone with good intentions gets brushed off and they just say "fuck it" and put their time and effort towards something else. When someone could fix the port but is denied the ability to do so, harm IS done. > >> [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). > Not the only one, unless you mean to say Jeffrey Bouquet is nobody... > >>> 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. > Quickly rectified and ports tree don't go in the same sentence... Also, I've done the steps of fix, stage, and claim maintership. The issue is "honestly be the maintainer". How can I honestly call myself the maintainer when I can't actually do anything to the port myself. I can submit a PR as maintainer just like anybody else. I can sit and wait for a committer just like anyone else. So what's the material difference? The port has my email address on it like a vanity plate. "Hey, this is mine, now you have to go through me too. haha!" One more level of abstraction. > >>> 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). > I have done exactly that. I recently picked up maintainership for two of the ports mentioned. Now, what can I do? I fixed them up so they build and install with staging. Getting them committed was the majority of the effort in that process. I have improvements I'd like to make, but I have to wait on someone else to commit that. My improvements might sit forever without being committed. With that total lack of assurance, there is zero motivation to do anything not of immediate benefit to myself. I'll make the improvements for my use, I'll throw patches into PRs for someone to maybe commit, and if that happens, great, I don't have to keep as many local differences against the ports tree and maybe some other users will benefit too. If not, well, too bad for the other users, I have my improvements for my use, I made the effort to share, but I won't go too far out of my way to enforce the sharing if some blowhards want to keep making it unreasonably difficult to do so. > > 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). > Sure, there's always disagreements, but part of keeping a functioning community depends on minimizing disagreement. I'm not saying staging should be dropped, but making it a requirement for commit just deters other bugs from getting fixed. "Ooh, I could fix this, but then I have to stage it too... meh, fuck it." > > 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. > Oh sure, PRs aren't ever wasted at all. Tell that to all the submitters of PRs that were not handled, or were handled all the way up to the last step and then forgotten. i.e. ports/188784 > >> 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. > Just because only 3 were revived doesn't mean the rest were trash. Maybe the other 47 had users who just aren't yet aware, or who have noticed but have no idea what to do about it. > > 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. > You mean it wasn't important enough to anybody who is *allowed*. That is FAR from everybody. It's zero effort to keep a port around. It takes effort to delete it. It takes effort to keep it around and keep it working. But to just keep it around, zero. > >>> 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". > Deprecation certainly seems to mean whack based on the statistics you gave. Thousands of ports pruned. Thousands of people made an effort to make a piece of software they wanted to use available to a wider audience, and their efforts were repaid with rm. That's really a great way to encourage new potential contributors. As to "no more procrastination", well, I'm about ready to just say "time's up" to the ports community. In addition to taking maintainership of a couple recently, I've been submitting patches where I either don't want to wait, don't want to keep the local diffs, or want to push the port ahead because I personally would like to see more users of the software for one reason or another. One such example is www/qupzilla, which I did the last couple updates for, and added options, all by throwing patches into PRs and waiting. I want the new versions, I want (one of) the options, and I want more people to try out this browser as an alternative to Firefox due to the unacceptable policy and code quality that comes from Mozilla. Well, I'm sick of waiting. The last update and options patch got maintainer approved and switched to open state a month ago. It's waiting for ANYONE (anyone with a commit bit that is) to commit it. Nobody has. The work is done, it's been reviewed, it's been deemed good, but that's not good enough, nooo. Neither I, the person that did the work, nor the maintainer of the port, who has reviewed the patches, can commit. We are powerless. We are pissing away our time to work on a port that could benefit other users, but for one reason or another just hitting commit is too damn hard for those who have the privilege to do so. Sorry, but waiting a month is utter bullshit. I have another patch for the next version, which was released almost two weeks ago. The patch has been done for more than a week, but I've not submitted in a PR because it's going to depend on the existing PR getting committed. Now I'm in a bad mood, so maybe I'll just put it in a PR with very pissy comments, or maybe I'll just keep it to myself. Too bad other users, the committers are slackers that won't let people with good intentions act upon them. > > 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). > That is extremely far from true. I regularly see things that could be easily fixed, but instead someone hits them with a hammer and calls it done. Maybe the hammer is a deprecated line, maybe a BROKEN line for retarded reasons (e.g. version bump), maybe the NO_STAGE flag without even checking if it's needed (yes really, I've staged at least one port by just removing that line, there was absolutely nothing in the port incompatible with staging, just nobody took the 5 sec to look), or other similar nonsense. Example: benchmarks/bonnie++ had USE_GCC for no good reason. I fixed it for Clang and called it done. But then, ironically, you jump on the PR complaining that it's broken on GCC and thus Dragonfly. I was very close to saying "too bad, I don't give a shit about either of those crapfests", but I decided to set an example for you and fixed it for GCC too. Really the prime motivation was to keep the first patch from getting reverted by anyone too dumb to fix it for GCC. I had already seen that nobody with a clue about C++ was paying attention or it wouldn't have been USE_GCC for months already. Now, DFBSD can't say I never did anything for them. > John I had kept distance from getting involved in the ports side because it always looked like a cesspool. After long enough avoiding it, I made the mistake of stepping in. Knee deep in this shitmess, I have a choice to make. I can keep throwing patches at PRs and hope somebody might just commit them, or I can say screw it all and just fork the ports tree in a public repo. I had a private branch or sorts for long enough, until infrastructure changes made it easier to restart. I could do the same again, just with a little more organization, and let other users pull from that public repo. As it is, I need to have a versioned branch anyone to deal with patches upon patches in any sane fashion. Anyone who wants could pull newer stuff. Anyone who wants could contribute too. All that matters is I cease to waste my time waiting for nothing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2827292.qM76QHi0yk>