Date: Thu, 15 Dec 2016 14:16:18 +0100 From: David Demelier <demelier.david@gmail.com> To: "Vlad K." <vlad-fbsd@acheronmedia.com> Cc: Freebsd Ports <freebsd-ports@freebsd.org> Subject: Re: (In)Stability of the Quarterly Branch Message-ID: <CAO%2BPfDcYDy=w9Xaf02zWiYNO38Yex0ioX6z4a-5KL8k7e9qgQA@mail.gmail.com> In-Reply-To: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> References: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2016-11-16 13:17 GMT+01:00 Vlad K. <vlad-fbsd@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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAO%2BPfDcYDy=w9Xaf02zWiYNO38Yex0ioX6z4a-5KL8k7e9qgQA>