[RFC] Why FreeBSD ports should have branches by OS version

Vlad K. vlad-fbsd at acheronmedia.com
Fri Jun 23 21:40:30 UTC 2017

On 2017-06-23 23:09, Grzegorz Junka wrote:
> Fine. Considering that maintainers already apply patches to the latest
> quarterly branch. If there were to be OS version branches, it would
> mean that maintainers apart from what they are doing now would
> additionally need to apply selected patches to those OS version
> branches?

"OS version branches" would be a complete waste of time and resources, 
and it would remove some level of separation/independence between the 
base and ports.

The crux of the problem here is so called "stable ports", not 
necessarily tying them to the life cycle of a base release. It doesn't 
make sense to tie version of a port to the base release. Especially with 
the new releng support schedule that would mean 5 years per major 
version which is quite a lot.

RHEL/CentOS achieve that with:

1. paid maintainers
2. far less packages to maintain
3. strictly supported set of enabled features/packages

Even Canonical is supporting far less packages in their Ubuntu 
"Universe" (officially supported repo), while tens of thousands of other 
packages are "Community support".

So that's two ecosystems with vastly more users and contributors. 
They're also ecosystems with strict policies in place so "volunteer 
time" excuse does not apply, the maintainers are expected to do certain 
things and to it as the policy prescribes it. From what I gather, 
something like this would be impossible in FreeBSD because nobody is 
"required" to do anything, "we're all volunteers" I've been told.

Another part of such a policy is commitment to maintain the package for 
the duration of release (in Debian/Ubuntu), to the extent of packages 
being removed if the maintainer is not committing as promised (which 
usually happens during freezes of next stable).

So the only solution is to maintain stable ports for the duration of 
their upstream life cycle. The problem was with node, so fine, support 
www/node6 for as long as upstream supports it. Anything else would 
require tremendous amount of work to cherry pick and backport from a 
codebase that is increasingly changing and making it much more difficult 
with each upstream release. if "www/node" is not obvious enough to mean 
latest node, then rename it to node-latest. As in this case (the 
original post of this thread), reading UPDATING would've sufficed to 
avoid any problems.

Another example is Roundcube. We have bumped roundcube to 1.2 last year. 
Personally I balked at this and kept 1.1 around in my local tree until I 
properly tested 1.2. Another example was irssi that was bumped from 
0.8.x to 1.x (and in quarterly even, and approved by ports-secteam!), 
breaking some plugins in the process.

But, given that example, under this new "stable ports" regime, there 
would be mail/roundcube11, mail/roundcube12 etc... Especially since the 
upstream continues LTS of older versions.

Again, nothing prevents the maintainers from doing it right now. No 
special project or repo is needed except the maintainers' will and time 
to do so, which is obviously lacking.

And I'll join the concerns expressed earlier, about people who are not 
familiar with a port, maintaining it. I've seen that cause breakages, 
because the committer doing the change does not understand the port, and 
am vehemently against it.

Vlad K.

More information about the freebsd-ports mailing list