Date: Fri, 23 Jun 2017 23:40:19 +0200 From: "Vlad K." <vlad-fbsd@acheronmedia.com> To: freebsd-ports@freebsd.org Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version Message-ID: <63e5c4e30a60d51c5a068177b9483206@acheronmedia.hr> In-Reply-To: <6d35f70b-17f2-d864-68ed-a3637cdc9fbf@gjunka.com> References: <CAO%2BPfDeFz1JeSwU3f21Waz3nT2LTSDAvD%2B8MSPRCzgM_0pKGnA@mail.gmail.com> <20170622121856.haikphjpvr6ofxn3@ivaldir.net> <dahnkctsm1elbaqlarl8b9euouaplqk2tv@4ax.com> <20170622141644.yadxdubynuhzygcy@ivaldir.net> <4jrnkcpurfmojfdnglqg5f97sohcuv56sv@4ax.com> <20170622211126.GA6878@lonesome.com> <n8eokc5fafda8gedtvbhh7i0qdk83gur5q@4ax.com> <594C4663.5080209@quip.cz> <09384577-ed7e-d142-43f3-0a08f5d21056@freebsd.org> <5eabe1d2-85a3-f7eb-a1ab-dc5552eb70fe@gjunka.com> <fa33d0e8-67cb-ab06-9a58-26dafe250f6c@freebsd.org> <6d35f70b-17f2-d864-68ed-a3637cdc9fbf@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63e5c4e30a60d51c5a068177b9483206>