svn commit: r514669 - in head: . Mk/Uses archivers/kf5-karchive devel/kf5-extra-cmake-modules devel/kf5-kapidox devel/kf5-kauth devel/kf5-kbookmarks devel/kf5-kcmutils devel/kf5-kconfig devel/kf5-k...

[Jan Beich]

Mark Linimon <linimon at lonesome.com> writes:

> On Thu, Oct 17, 2019 at 06:06:42PM +0000, Tobias C. Berner wrote:
>
>> This release is part of a series of planned monthly releases making
>> improvements available to developers in a quick and predictable manner.
>
> Ouch.  I know it's probably impossible to ask this, but ... is there
> any way we can limit the rate of change here?  e.g. by -devel ports
> or something similar?

KDE Frameworks ports are updated roughly once a month. Is that too often?

>
> Here's my worry (speaking as a powerpc64 guy).  The big commit comes
> in; it takes several days for even one of our fast machines to catch
> up; then if we find any problems, more time to test patches; then
> time to submit/process the PR; only after which are the official
> package builders guaranteed to get the right result.

Stop building /latest for -CURRENT on the same machine as /latest for
-RELEASEs. Each __FreeBSD_version bump makes poudriere obsolete *all*
packages. According to ministat(1) for 11.2 amd64 the average number
of /latest packages built each cycle is 8246.

When testing a fix don't update local ports tree unless there's a change
in the port being fixed. Some (or maybe a lot) of ports/ committers
don't have a fast machine to test changes even on Tier1 architecutres,
so learning how to cut corners helps. For one, poudriere obsoletes
packages in a chain reaction but the chain can be cut at indirect
consumer boundary thus saving time on pointless rebuilds: opencv-core ->
ffmpeg -> qt5-webengine where qt5-webengine rebuild can be avoided by
rebuilding ffmpeg separately.

>
> w/rt powerpc64 especially, there are so many fast-moving large
> changes right now (base system compiler, ports gcc compiler,
> ports llvm compiler) + x11 + uh, whatever else, that IMHO we are
> moving farther away from our goal of having a usable package set
> (especially for ports-head) rather than closer.
>
> Your opinion?

FreeBSD is not moving fast enough from desktop POV (see recent shift to
Linux by Trident project). Currently, the rate of ports/ changes is
already limited by the awkward FreeBSD workflow. Once the project moves
to GitHub (or similar) the rate may slightly increase but the true
blocker is pre-commit automation.