On 15.12.2016 14:16, David Demelier wrote:
2016-11-16 13:17 GMT+01:00 Vlad K. <vlad-f...@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
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
