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

[Torsten Zuehlsdorff]

On 26.06.2017 21:33, Grzegorz Junka wrote:
> On 26/06/2017 07:24, Torsten Zuehlsdorff wrote:
>> Aloha David,
>>
>>> I think the current process of having rolling-releases packages makes
>>> unpredictable upgrades as we have to manually check if the upgrade
>>> will be fine or not. When a user installs FreeBSD 11.0 on its system,
>>> it probably expects that everything will work fine until a next major
>>> upgrade like 12.0. That's why I think we really should implement
>>> branches for a specific FreeBSD version.
>>>
>>> When FreeBSD 12.0 is released, we should create a ports branch that
>>> will contains only fixes (such as security advisories, crash fixes and
>>> such). No minor or major upgrades until a new 13.0 version is
>>> released. This is the only way to make safe upgrades.
>>
>> The discussions did go on for a while, but lets get more technical. 
>> While i can understand your use case, it raises various questions:
>>
>> - How should be EOL-Software handled? For example PHP 5.6, Typo3 7, 
>> PostgreSQL 9.2 and many more will expire long before FreeBSD 11 
>> expires but are still valid (or even default version) when created. 
>> Since the versions are frozen, how should - at least- security issues 
>> handled?
>> [Yes, i read that a user can switch at its own risk to another branch, 
>> but lets assume he is very fine with the version (because i have such 
>> customer)]
>>
>> - How should be new dependencies handled? GitLab for example sometimes 
>> *requieres* updates of its dependencies in order to fix security issues.
>>
>> - Same as above: how should be dropped dependencies handled? In worst 
>> case we need to maintain them for nearly 5 years, but nobody (should) 
>> use them
>>
>> - How to resolve conflicts? I mentioned GitLab above and now realize, 
>> that sometimes the GitLab update breaks for example www/redmine 
>> because it depends at other versions than GitLab.
>>
>> - Where do get the fixes from? We have around 26.000 ports which needs 
>> fixes in worst case
>>
>> - How to handle for example security issues only fixed through an 
>> update? Which such a long time between "updates" it gets very very 
>> hard to port/get/write patches in fast developing software. Wordpress 
>> or Gitlab are typical examples with thousands of lines in code-changes 
>> every update
>>
>> - How to make the customer clear, that complains about the software 
>> (old, outdated, missing features, unresolved bugs, etc) are intentional?
>>
>> - Where to archive the distfiles? Sometimes upstream completely remove 
>> them from everywhere they can.
>>
>> And last: how to make updates from FreeBSD version to version easier? 
>> Many user already have problems with single major updates. From my 
>> experiences in Windows or Ubuntu LTS usages with such or very similar 
>> version handling: the update, even of the OS, is pushed as far away as 
>> possible, because of the big amount of work required, since everything 
>> needs to checked/updated/changed.
>>
>> I have a hard time to image, that is handled in another way by you. So 
>> if you can me give more insight about your use-case i would be happy 
>> to read it for a better understanding.
>>
>> I have various customer requiring (and paying for) very old software 
>> (for example still PHP 5.3). So i know some of there motivations, 
>> which boils every time down to "its to expensive to upgrade our 
>> software" [but they don't mean expensive in money]. So maybe we can 
>> make something happen. 
> 
> I understand a stable ports branch would be required by specific 
> applications (of the FreeBSD system), e.g. data centers, bespoke private 
> solutions, home servers. Therefore not all 26.000 ports would need to be 
> security-patched. In fact, I believe it would be viable to determine a 
> thousand or two of ports mostly used in those environments and commit to 
> patch only those.

Yes, but even with a subset of the ports-tree neither of the above 
problems is addressed!

> Even RedHat, which is a model example, doesn't commit to maintain all 
> packages, just a selected set of them. In the similar fashion to having 
> Tier 1, Tier 2 and Tier 3 supported platforms for FreeBSD, we could 
> start small with a just a handful of ports in a stable LTS (Long Term 
> Support) branch. Develop processes around maintaining them, get some 
> feedback about the effort of applying only security fixes, then add more 
> ports as required or as viable from the resources point of view. How 
> does that sound?

This didn't address any of the issues mentioned above. Nor from other 
threads.

But to be clear: since i already do such things (on a much smaller 
scale) i have no problem with this idea. But since i'm already get paid 
and know the work behind it, i wont do it for free.
Even do setup a minimal QA infrastructure needs money and maintenance 
and just build-tests are not enough.

Greetings,
Torsten