(In)Stability of the Quarterly Branch

[Olivier Duchateau]

On Thu, 15 Dec 2016 14:16:18 +0100
David Demelier <demelier.david at gmail.com> 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.

Are your serious when you said, there're no tests on FreeBSD ports. I can tell you Xfce ports are tested with FreeBSD i386 9.3 and amd64 11.0 machines (on real hardware, no virtualization), and on poudriere with Gtk+ 3.20 (port version is not not in ports tree, it's defaut toolkits for the next stable release 4.14).

For the LXQt desktop is the same thing (tested with official ports tree Qt5 and which one in plasma5 branch (on KDE repository).

I'm also working on the Pantheon desktop (desktop environment of Elementary OS, I use Vala 0.30.2 and Vala 0.34.4, in order to test stability of applications.

I use also OpenBSD macppc, it's piece of shit. WebKit browers are broken, Xfce components crash often, stable branch is outdated, fix are not propagated in stable branch. Personally I prefer the FreeBSD scheme, because I'm sure it's quite stable.

> 
> 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.
> 
> Waiting for more stability, I really encourage people to use poudriere
> to build packages to avoid breaking a system at each upgrade.
> 
> Regards,
> 
> -- 
> Demelier David
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"


-- 
olivier