Unmaintained ports or “quantity vs. quality”
There were a lot of discussion on FreeBSD ports tree last few month. For example, it has been noted there’re a lot of unmaintained ports (freebsd-ports@, mid ) and ports collection is very large (freebsd-ports@, ). So, it looks like a number of ports grows much faster than a number of maintainers. I have a few thoughts on it I want to share with you.
-
New ports
IIRC, some time ago it was decided not to accept new ports where MAINTAINER=. It’s obviously a good idea, though I’m not sure if all ports committers follow this recommendation.
But there’re some more problems. First of them: there are a lot of people submitting “useless” ports, e.g. a search engine for mails using PostgreSQL. Man, it’s crazy! But it’s not the worst case, there are some ports I barely believe somebody actually uses. People submit ports just because “wow, new thing, dunno why I need it but I’ll make a port”. I have a strong opinion: if you don’t need this app, don’t create a port for it! You might say: it’s good for end uses to have as much ports as possible. Yeah, in general it’s true. But take into account that if a person actually doesn’t use a ported app, the port will be bad. Just imagine: end user installs some software from ports and sees that the software doesn’t work, because a maintainer e.g. updates the port, but doesn’t even launch it and that way doesn’t know that this software core dumps on start for example. End users asks maintainer: it doesn’t work, help me! And maintainer says: I don’t know how it works, I don’t know the programming language it’s written in and finally I cannot reproduce this bug ’cause I don’t use this app! What we get as a result: sad end user and one more useless port. So, how do you thing, is it possible to make a good port if you don’t use the app? And what is better – bad port and no port at all?
2. Ports without maintainers
As it was mentioned above, many ports have no maintainer. I think that once port lost its maintainer, it should be scheduled for removal in, say, half a year. Instead of it we do the following: we leave things as is. Futhermore, some people start local mini-campaigns fixing such ports. They do updates, they fix master sites and stuff. It’s bad. All the reasons from part 1 applies here too + they don’t even feel responsable because they actually don’t maintain that port.
So, I think users vote by feedback/submissions/contributions in open source. If nobody wants to adopt a port, it should be removed. If user has not enough skills to adopt existing port or create a new one, he/she should ask for help some more skilled users. And that more skilled users should not create ports only because their skills are high enough to do it.
IMO, having 5000 ports in a very good shape are way better than having 15000 ports in a bad shape.
While I totally agree with you on the last statement, I must say that the reason why I love FreeBSD is the ports count. Admitted I stay within the range of the popular ones—probably the most maintained ones— but knowing that a `portinstall whatever` has a 99% chance of success is truely appealing to me.
Consider people who, like me, don’t know jack about C or C++ let alone makefiles. The ports system is a blessing for those ./configure-make-make-install challenged people especially when you encounter lots of so-called “run on any unix” programs full of linuxisms.
I actually wish I had found a system as robust and well-maintained as this on my new Mac. I’ve heard about darwinports, but for the few packages that I tried to install it didn’t go as smoothly as on my freebie box. Granted, I’m new in the Mac business, I probably need time to adjust.
Of course sometimes a port gets broken (I’m working on a PR after a recent update to GraphicsMagick that broke at least pecl-imagick), but it doesn’t stay in that shape very long. Ultimately, the issue is discussed on freebsd-ports@ and a solution is found. Moreover, working in a Perl shop, having 2500+ p5-* ports at hand is a dream. Spending the last day upgrading a 2-year-old 4.10 server, base and ports, was a painless process.
Back to the issue you raised, I’d like to share a few suggestions.
What about tagging the ports for which maintainer’s timeout occuredi? Those could be put in a file alongside UPDATING and MOVED so interested people could eventually pick them up for adoption without having to browse the whole tree. If there’s no sign of interest for the port after a certain amount of time it gets deleted until someone really needs it and accepts the responsibility of maintaining it. It can be discouraging to submit a PR, watch it rot in the queue and eventually have to go on IRC begging a commiter for him to have a look at it.
About reducing the ports count, if I remember correctly a couple of years ago a similar issue was raised and the idea of a separate ports tree a-la pkgsrc-wip was proposed. The idea was one, to filter the ports and move to the official tree only the true, stable, tested ports and second to “train” people on the duties of maintaining a port (I’m always curious when I see several commits for the same port within a few days, the latter being on fixing pkg-plist files).
Anyway, I think that FreeBSD has a great, newbie-proof, still advanced 3rd-party apps system thanks to the amazing job of the ports team. Anything to improve it could only benefit the community.
G.
For the first problem, another suggestion is to add new ports only if there are at least two people that want this port. (e.g. Bugzilla has a voting system for bugs)
I think 2 is definitely wrong, take print/ghostscript* as a counter example, it is unmaintained since 5 years and still works (mostly) :-).
I prefer to have no maintainer over an unresponsive maintainer.
And i think most of our 15000 ports are in quite good shape…
I also kinda like the idea of the voting process that debian uses.
It’s not too late to revive portrookies. I have some ports that i’m not sure i want to maintain. I think they better be in that tree than rotting on my hard drive.
Now if we expect people to use this alternate subtree, we must provide tools to integrate it correctly in a genuine ports tree (a bit like marcusmerge).
Re: maintainer-timeouts: I have the last 18 months’ worth in some flat text-files. Although I have reset a few ports, I’m somewhat behind on this task. We definitely need some better tools than what we have now (including to track packaging-status); I am currently working on some ideas for portsmon.
Re: which ports are ‘important’ ports, and/or coming up with a process to screen port submission: people should be aware that there is past history that indicates to me that there are people who will strongly resist adding ‘process’. My advice is for people to set their expectations accordingly. (The only thing we have for the former is # of people that subscribe to FreshPorts, and that’s only a good indicator of positive interest, not a good indicator of lack of interest, because not everyone subscribes.)
Re: maximum number of ports we can support: clearly there are limits. The one that we are hitting up against now is that it takes 2-3 weeks to build packages for amd64/sparc64 on the build cluster, which at some point will limit our ability to do release engineering. Secondarily is that with current technology, all users have to maintain all the port Makefiles. (Solutions to this have been discussed but are outside the scope of what I am going to write in this followup …)
To some extent this all relates to “what do we want the Ports Collection to be?” which does not currently have a consensus. Some people want it to be “every possible thing”, some want it to be “only useful things.” I’m not sure how to try to forge that consensus …