A new experimental fork for the ports tree

Hello!

I have a suggestion, which may help decrease the time needed for certain ports to enter into the ports tree.

The division of the base system into different forks like 9-STABLE, 8-STABLE, 10-CURRENT, 9.1-RELENG, 9.0-RELENG and so on is a great idea. This way, people can checkout the version that suits them best, and join in to help as developers, or as testers. I suggest a similar approach for the ports tree.

Currently there are more than 150 new ports waiting to be accepted into the ports tree (those PRs still remain open). Some of them are awaiting confirmation even from 2010.

I suggest an experimental fork of the ports tree, which would include volatile ports, that wouldn't necessarily build, and people who would be checking out this fork could help debug them. Also, restrictions to get your port commited in this ports tree would be lesser -- it would be pretty easy for even a bad port to get inside, but until the port issues are resolved, the port would stay there (potentially indefinitely, unless the norms are met).

It's just an idea. It may happen, that the community wouldn't be as helping or as motivated as I think, so it could be there on trial for a few months to see what would happen.
 
Have you suggested this on the ports mailing list yet? I don't seem to recall having seen it come by there.
 
Your idea isn't new and it has been suggested many times on the ports mailing list. I believe the main reason it hasn't happened is that the bulk of the developers working on ports do not actually have commit rights, they are hacking away on their private repositories and then submit their patches to developers who do have commit rights to have their work committed. Now imagine what happens if there was a separate experimental branch of the ports tree and port maintainers/developers wanted to commit their experimental patches that would be much more numerous than the usual patches because of the experimental nature of the work. That would put enormous pressure on those with commit rights.
 
It's been suggested. There are two main reactions to having -STABLE and -CURRENT branches on the ports tree:
  1. Great! Now we can have cutting-edge stuff in ports!
  2. Awful! Now maintainers and committers have twice as much stuff to try to make work!
There have been arguments both ways. The limited number of people available is probably the biggest reason it has not happened so far. It still might.
 
One solution would be a GITHUB type system where anyone can submit a pull request and the system takes away much of the manual work of commiting patches allowing the developers to focus on verifying that the patches are good and valid. Since FreeBSD uses SVN as its main revision control system I'm not sure such system is easy to implement around SVN.
 
Well, I sent the email. In it I also suggested sub-maintainers: people from the community that have been helping to patch the ports up would be listed there when a command like # make -C /usr/ports/some/port maintainer has been invoked. When the port would be ready to enter the "good" ports, all those sub-maintainers would be left out.

Also, I would lift the restriction for commit rights. There could be a mechanism similar for subscribing to the mailing lists -- you subscribe for let's say 1 month temporary commission "license" and select only a subset of all ports to which to commit to. You'd get a password via email, and that's it.

But like I said, this experimental fork could be there on trial for let's say 2-3 months, just to see what would happen.

PS: And it wouldn't be about bleeding edge. It would be more like ports that have great problems and can break your system. So it would be more like for debugging with a group of people.
 
Yep, good idea but a lack of resources also plays a big part. We'd all like to have proper package repositories too. Don't forget a single ports tree already gets built at least four times, for 8.x-i386, 8.x-amd64, 9.x-i386, 9.x-amd64. With 10.0-RELEASE two more will be added (8.x needs to be supported for a while). I'm not even counting the other architectures FreeBSD supports. And if you're going to add another ports tree it adds up exponentially.
 
But the whole point of it would be that it's experimental, so no packages would have to be supported from it, but only (broken) ports (you cannot make a package if a great deal those ports don't even build). Also, no resources would be needed for testing with pointyhat for example -- that would be up to the community using that fork.
 
Why not commit your test ports to redports, where you can easily gain commit privileges to your own ports repository? Others could easily checkout this repo and test some of your ports manually. There is even a build cluster behind redports to fetch errors.
 
Well that settles it for me. If you can test your own experimental ports in https://redports.org and also share your experimental work to others, is there really any need for an experimental branch on the official ports repo?
 
Wow! That's really cool! I didn't know about that! I'll visit it as soon as I have some time! Thanks a bunch!
 
Back
Top