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