Date: Mon, 21 Oct 2019 14:45:01 +0200 From: Jan Beich <jbeich@FreeBSD.org> To: Mark Linimon <linimon@lonesome.com> Cc: "Tobias C. Berner" <tcberner@FreeBSD.org>, svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: 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... Message-ID: <zhhu-8dyq-wny@FreeBSD.org> In-Reply-To: <20191020233557.GA4508@lonesome.com> (Mark Linimon's message of "Sun, 20 Oct 2019 23:35:58 %2B0000") References: <201910171806.x9HI6g9e044915@repo.freebsd.org> <20191020233557.GA4508@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Linimon <linimon@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?zhhu-8dyq-wny>