2016-11-16 13:17 GMT+01:00 Vlad K. <[email protected]>: > 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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
