Fyi, four languages without a maintainer/port

So the title of the post is specifically about 4 languages that are unmaintained, but the thread has morphed into
"unmaintained ports".
I think is a general statement on "third party software".
Someone creates something you need like a window manager. You start using it, it evolves eventually the creator stops "creating/maintaining it" because of time or interest. What do you do because you use it?
I don't know the answer. I think something that gets to "how many people actually use a given port" vs "is it maintained" is really needed. A port without a maintainer that noone uses means nothing. A port without a maintainer that 1K people use, needs a maintainer.

I know some of the WindowMaker apps I use report "no maintainer" and I'm not willing to step up, so I'm accepting that "at some point in the future they may disappear".

Yes, I know "mer blah blah blah blah" ;)
 
Thanks to several people in the thread and forum for their guidance. I can't name them all.
I'm one of those who happen to know what you're working on. I will of course respect your wish to not make it public unless it's fully done! What I can say is: this will be a pretty valuable addition to our ports tree, at least for (some!) desktop users.

You are one of those with little experience with make and other build systems, with packaging practices in general. And admittedly, this makes it a lot harder to start working on ports. But you also showed your willingness to learn and take advice, and this is the attitude it takes! I'm pretty sure you will make a great maintainer for your new ports. And rest assured, the more experienced crowd is always very willing to give advice and guide new ppl. So, I'll just take this opportunity to say in response:

Thank you for starting to work on FreeBSD ports! 👍

And mer, sure, this went off-topic. But I still don't really get the point of just naming a few eso-langs. There are lots of unmaintained FreeBSD ports. This is a great opportunity to remind everyone that FreeBSD (src, ports and doc) is a community project, and everyone's input is more than welcome! And also: everyone can learn to contribute, it's no rocket science ;)
 
There are other github clones i use:
-dub (in ports but old)
-glrnvim
-gnvim
-sfwbar
-ping_exporter
-cups_exporter
-postgres_exporter

In theory making a port for each of them should be strait forward.
 
The second part isn't worth the effort, I don't have statistics, but in my personal experience, the majority of port upgrades aren't "trivial" (only change the version variable an regenerate distinfo). And even those that are must be tested anyways.
They may not be regular enough to automate (easily) but at least the few I have tried have been relatively easy to fix. May be a better option may be to create a port helper program that automates as much of the repetitive work as possible. I play with this idea some and see if I can come up with something useful.

Testing seems to be completely port specific - some of them don't even have any tests.

portscout already does the first part so no need to repeat that work.
 
Jokings aside games/xlennart is unmaintained.
That port is current with the latest distribution minor point release. The underlying software is unmaintained/defunct. This is a different situation entirely.

Tell us if you've experienced any problems with the current port running on a 13.1 or 12.3 release of FreeBSD, including the display manager you've chosen to use it with and perhaps briefly the combination of hardware used which may have a pertinent influence on your issue.

As the game is very old, arguably lame, a momentary satirical whimsy of its author, a knock off of a game over a quarter of a century old fitting the same description, ultimately just a gross triviality, please don't be surprised if no one responds or cares. I mean that in the most compassionate way.

On the other hand, XBill is an important part of open source history and heritage, in an ideal world its compatibility and function should be maintained, so to bring XLennart along with such efforts should not take much additional effort.

We are more concerned with FreeBSD ports which fall behind their active software projects' iterating versions, items 3 and 4 of your original post, or useful/popular open source software lacking a FreeBSD port altogether, a class that items 1 and 2 may fit. In either case while it is not ideal it is no catastrophe, as the Porter's Handbook is well written, the Portstree [and Framework] relatively well engineered and quite actively maintained, and individual members of our community often write or update many a port though Bugzilla without taking on the responsibility or obligation to become maintainer of a port to which they contribute.

I wonder if poorly managed ports aren't more detrimental than unmaintained ports. I for one feel I am guilty of lackluster maintenance of ports upon which my claim may possibly thwart or discourage others' adoption or collective maintenance, while I imagine one potentially who waits for my action, as I am prone to suffer arbitrary or sudden bouts of incarceration and all other sorts of work/life balance mismanagement. At any rate, I'm back on my task, at least for the time being, and I have always felt supported and assured by this amazing community.

I hope that instead of feeling pressured to either accept liability and obligation to maintain a port, lest in frustration you otherwise leave us in defeat for potentially a more trendy [yet fleeting] open source distro of likely less well thought out architecture and engineering, rather you'd please feel our encouragement to try and simply contribute to these ports. When one exhibits the courage to try publicly and yet fail miserably, orders of magnitude more attention and support will mobilize to their aid from the community.

I am living proof that one can make a successful career, maybe a legacy even, of pathetic failure with public embarrassment as angels among us have lifted me to higher levels of productivity, greater freedom and responsibility, than I ever dreamed possible of attaining for myself, in such a manner I could not find among any other software development community on Earth. However you will not find a post or email of mine going back decades in which I stood apart to point out flaws with an aloof or dismissive delivery, nor made suggestions while trivializing the effort required, nor threw my arms up at an early stage of despair to ask for help in a defeated tone. (Not saying that's exactly what you've done but yet it may describe something close to how you're being perceived.)

If you will please tell us your overall objective(s), not merely your narrow problem(s), then, no matter how trivial or meaningless it seems to be, I will certainly do my very best to help you (provided it shows that you've sought your own way somewhat deep into either the Porter's Handbook and/or a third-party project's README, with a certain level of perseverance only to find yourself well past your comfort zone). And so when, try as I might, I too fail miserably to help you, as I myself am woefully inept, then, I'm willing to bet upon it, a band of these heroes mightier than us shall materialize out of the woodwork as they or their ilk always have before, for a grateful me, in every single instance of my desperate need.
 
What is needed is a program that watches the original source sites for various ports and when there are updated sources, it tries to update a port using the existing port and stashes results in somewhere. Such changes often quite trivial so it makes sense to automate at least the grunge work.
Another way in which identifying when the last update to a port or different compared to a sourcetree would be helpful, even considering that it can't always automatically be done due to the need for testing is, it lets others including those who are coming to FreeBSD know which ports are not obsolete compared to sources. It will be a reference so they know what's newer, and will bring action and new users. It will make it easier on prospective users, and let them know, rather than them coming in having to investigate for a long time, then decide it doesn't have what they want and leave. This way, they can look at it before coming, then ask about that, and it would be quicker for them to decide or for an updated port to get implemented, then they come in. It will also let regular users know where the version they're using sits at. Otherwise, it takes investigation and deep diving by regular users, and for something they've been interested all along, it may take a long time to stumble upon years later.

Recent examples are Samba versions, Xaw3d, and Blender derivatives. Blender was actually very much up to date, and well put together, at the time it was heavily inquired about, but months before that, it may not have been. Either way, if Blender or a Blender derivative didn't have experimental features, they could see that, then go elsewhere or look into that.

It would be something like how checking a hardware list to see if a particular hardware works with FreeBSD, except for software availability and software versions.
 
Another way in which identifying when the last update to a port or different compared to a sourcetree would be helpful, even considering that it can't always automatically be done due to the need for testing is, it lets others including those who are coming to FreeBSD know which ports are not obsolete compared to sources.
That information is already available via https://portscout.freebsd.org/ -- you have to click on the name of a maintainer to see the ports that need updating.

Or do you want something more?
 
It's lacking a bit. It shows when it was last updated, and assumes, because that was in the last few months, it doesn't take into account when upstream of a port changes the source location which often happens when it changes hands. Also, locations of the previous download source could be the one that wasn't an official mirror that goes stagnant, while the upstream got upgraded elsewhere, and sometimes the name changes. This may require manual intervention though.

There was one, but it needed testing for them to upgrade that. For example, Xaw3d which later became libXaw3d at a different upstream location as has it changed hands. That needs to be included there. However, that one could simply be dropped for libXaw3dxft, while this has an opportunity to become the default.

Also, that one needs to be searched by the maintainer, and then by the port. Which, it refers to FreshPorts, and Freshports doesn't have that function.

Also, Portscout has a function on the mailing lists. It would be something like that, but a bit more.
 
Back
Top