On 8/12/2016 6:05 PM, Vlad K. wrote:
On 2016-12-08 06:16, Daniil Berendeev wrote:
I mean, they are the FIRST landing point of a change. And the only
QA we ask for that change is a confirmation that poudriere and
portlint have been run, the rest is at liberty of committers how far
they'll go with own testing before they commit. For many, only
builds against -CURRENT or latest -RELEASE are done because it's
very time consuming to test against all supported FreeBSD versions,
and not just versions but various permutations like different
pythons etc... When it comes to some defaults like OpenSSL (or any
kind of dependency on it), all of those tests are required.
The problem is, FreeBSD doesn't have a STABLE repo that would
receive gradual updates from HEAD as they prove themselves stable.
QUARTERLY != STABLE, it's just a snapshot of whatever state HEAD is
in, with a loose promise the ports in it will receive "security and
bugfixes only" but that's a separate set of issues.
The problem I get hit by is that the quarterly packages are deleted
immediately on the creation of the next quarterly set.
so by definition, when you've spent 3 months getting the quarterly pkg
collection reliable and correct, it gets deleted.
I think there should be two quarterly pkg collections available at any
time:
The one we are stabilising, and the previous stable set (called beta
and stable or something like that).
the stable one is basically read-only except for security fixes.
As it is when you get the new quarterly packages, they are straight
off head, because the branch was just made.
There are some solutions and we don't have to NIH or reinvent the
wheel. Just looking at what other open source projects do with, say,
GitHub and continuous integration testing, every pull request gets
an automated test. Why don't we do that? Is it difficult to
implement it?
I am also convinced that such testing can be automated and a true
"STABLE" repo can be made instead of manual QUARTERLY that breaks
promises.
I think this is heading in the right direction.. at the end of the 3
month stabilisation it goes to stable.
8) ports with vulnerabilities.
They exist in the tree and on build attempt they shout that they won't
build without DISABLE_VULNERABILITIES=yes. The catch is that there is
always a bunch of ports with vulnerabilities. So if you are doing a
That's just a nature of it, and the consequence of VuXML being a
separate port that gets often updated first, as it's better to
announce the vuln before it was fixed. And fixing is bound to
maintainer timeouts, poor issue tracking via Bugzilla, etc...
I hope that my mail will produce a productive discussion that will
lead
to some good decisions for fixing these problems.
Probably not. I've already posted about issues with head/quarterly,
hoping for a discussion, never happened. Others have complained
about the same problem, but no constructive discussion ensued. Is my
frustration coming through, yet? :)
yeah it's not working well at the moment. The procedures could do
with some tuning for sure.
_______________________________________________
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"
