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.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
