Date: Thu, 15 Dec 2016 14:43:30 +0100 From: Torsten Zuehlsdorff <mailinglists@toco-domains.de> To: David Demelier <demelier.david@gmail.com>, "Vlad K." <vlad-fbsd@acheronmedia.com> Cc: Freebsd Ports <freebsd-ports@freebsd.org> Subject: Re: (In)Stability of the Quarterly Branch Message-ID: <2bd42508-a1f9-b0f2-e329-51af36604a45@toco-domains.de> In-Reply-To: <CAO%2BPfDcYDy=w9Xaf02zWiYNO38Yex0ioX6z4a-5KL8k7e9qgQA@mail.gmail.com> References: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> <CAO%2BPfDcYDy=w9Xaf02zWiYNO38Yex0ioX6z4a-5KL8k7e9qgQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15.12.2016 14:16, David Demelier wrote: > 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. 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. Greetings, Torsten
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2bd42508-a1f9-b0f2-e329-51af36604a45>