(In)Stability of the Quarterly Branch
mailinglists at toco-domains.de
Thu Dec 15 13:43:40 UTC 2016
On 15.12.2016 14:16, David Demelier wrote:
> 2016-11-16 13:17 GMT+01:00 Vlad K. <vlad-fbsd at acheronmedia.com>:
>> The quarterly branch (Q) is intended to provide a set of "stable" packages
>> that in the lifetime of such a branch, receive only bug and security fixes.
>> That is the theory and intent behind the branch. In practice, however:
>> 1. The Q branch is cut off at predetermined dates (ie. not when it's stable
>> and ready), and it is cut off from HEAD, thus including the state of ports
>> at that moment. This breaks the promise of stability and guarantees that
>> every 3 months there will be uncertainty as to whether the fresh new
>> versions are working or not. There is no such thing as a "Pre-Quarterly
>> repo" which would receive all updates for the NEXT Q branch-off, and which
>> would freeze and stabilize for some time before branch-off. And even if it
>> did, 3 months would be too short.
>> It is effectively not much different from tracking HEAD and doing updates
>> only every three months, with the added benefit that SOME security updates
>> will come down sooner. But:
>> 2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a
>> bugzilla triager I've had the opportunity to observe this in practice. It
>> can be as simple as accepting a minor upstream version bump, or as complex
>> as requiring cherry-picking and backporting code if upstream mixes security,
>> bug fixes with new features. It is none-the-less a manual work requiring
>> ports-secteam to review and accept the patches. It is not clear who is
>> supposed to do cherry-picked backporting if the patches to HEAD cannot be
>> MFH'd as they are. It is also additional burden to the ports-secTEAM which
>> at the moment is, effectively, one person.
>> As it is obvious that the promise of a stable repo in its current form
>> requires manpower and manual work which we do not have, my proposal is to
>> abandon the promise of "security/bugfix" only changes and adopt the approach
>> not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates
>> from HEAD, but only after certain criteria has been met, like minimal age of
>> changes, no open issues, a certain battery of regression/integration/unit
>> tests is performed, etc...
> The problem is that there are no tests in FreeBSD ports. All source
> based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo;
> FreeBSD is the one that have the most instability. Not to mention
> committers that commit without testing the port, just look at
> www/redmine to get your point of view on that issue.
www/redmine is a special case like for example GitLab. This are ports
based on rubygems and the ports-tree has a hard time to replicate the
gems. When one port need an update for a specific gem another can break.
Other systems avoid the problem by ignoring it. You need to install and
maintain all gems by yourself. This includes updates, security checks
and of course installation of dependencies.
> On the other hand, your idea is indeed good and could be a good start.
> Quaterly branches change too quickly. That's simple: each time I
> install a new port, I'm behind 2 or 3 quarters the last one. So I
> usually update all before installing the new one.
> What I want: a ports tree that matches the FreeBSD version like
> OpenBSD. You have FreeBSD 11.0? You get a ports tree for that version
> specifically. No major update, no breaking changes. Just bug fixes.
> That will also simplify a lot FreeBSD ports by not having thousands of
> conditional checking the FreeBSD version.
That what i really, really, really NOT want. I have regular problems
with our admins because of that. You want a specific version of an
software? No problem: just install a specific version of your operation
system. Need two of them, but they are not in this bundle? To bad, than
you need a new server. This is an daily-base scenario i really don't
want to port to FreeBSD.
Yes, there are problems and tests are very helpful. But you need to
check why something is broken. Often the upstream is broken, not the
port. In the case of redmine the ports-tree lacks the pessimistic
operator which can catch many of the breaks in the last. It is one idea
to teach the ports-tree how this work. Also there is an ongoing effort
in increasing the tests. Every help is appreciated!
> Waiting for more stability, I really encourage people to use poudriere
> to build packages to avoid breaking a system at each upgrade.
This is a good idea. But does not help everytime. Many rubygem based
ports build just fine, but fail afterwards.
More information about the freebsd-ports