Date: Wed, 28 Jun 2017 08:56:51 +0200 From: Torsten Zuehlsdorff <mailinglists@toco-domains.de> To: Grzegorz Junka <list1@gjunka.com>, freebsd-ports@freebsd.org Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version Message-ID: <a9ecc546-800f-7479-bcf4-7eefdb8d357c@toco-domains.de> In-Reply-To: <77c15a0a-fde0-b240-803e-b369ebf0b897@gjunka.com> References: <CAO%2BPfDeFz1JeSwU3f21Waz3nT2LTSDAvD%2B8MSPRCzgM_0pKGnA@mail.gmail.com> <2f23f3d0-dcb1-dc12-eb9f-c8966a10f5f7@toco-domains.de> <77c15a0a-fde0-b240-803e-b369ebf0b897@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a9ecc546-800f-7479-bcf4-7eefdb8d357c>