Date: Mon, 12 Dec 2016 07:44:47 -0500 From: <scratch65535@att.net> To: freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: The ports collection has some serious issues Message-ID: <5s3t4c576qeivfr32d2j7u1fm8jkia97jf@4ax.com> In-Reply-To: <aea50699-2938-0fee-38bc-1bcdf4b7f8cc@ShaneWare.Biz> References: <c5bc24cc-5293-252b-ddbc-1e94a17ca3a8@openmailbox.org> <20161208085926.GC2691@gmail.com> <odkr4cdf8dant07thrav2ojn7bng98noj9@4ax.com> <ba08610a-3536-b347-c802-ca134b296246@unfs.us> <aea50699-2938-0fee-38bc-1bcdf4b7f8cc@ShaneWare.Biz>
next in thread | previous in thread | raw e-mail | index | archive | help
[Default] On Mon, 12 Dec 2016 17:01:33 +1030, Shane Ambler
<FreeBSD@ShaneWare.Biz> wrote:
>On 12/12/2016 13:12, Janky Jay, III wrote:
>> Hello scratch,
>>
>> On 12/11/2016 03:35 PM, scratch65535@att.net wrote:
>>> I have to admit that I avoid ports if at all possible because
>>> I've hardly ever been able to do a build that ran to completion.
>>> There's always some piece of code that's missing and can't be
>>> found, or is the wrong version, et lengthy cetera. I've never
>>> done release engineering, but I honestly can't imagine how some
>>> of the stuff that makes its way into the ports tree ever got past
>>> QA. It would get someone sacked if it happened in industry.
>>>
>>> If the dev schedule would SLOW DOWN and the commitment switched
>>> to quality from the current emphasis on frequency, with separate
>>> trees for alpha-, beta-, and real release-quality, fully-vetted
>>> code, the ports system might become usable again.
>
>Note that there are over 26000 ports, over 1600 port maintainers and
>hundreds of third party projects get updated every day. While the port
>maintainers spend a good portion of their spare time trying to keep it
>building there will be times that some ports fail to build.
Which, I think you must agree, is a prima facie case for
lengthening the release cycle.
Too few people trying to do too much work in too little time is a
receipe for disaster. I've seen it in industry, where
engineering gets tasked with impossible schedules to meet some
business plan dreamed up by the suits. Burnout City. After I
left the corporate world I used to do QA gigs as a consultant for
easy money, and the guys who'd hire me would have a hard time
suppressing their irritation because I'd find lots of bugs for
which they had no time in their schedule to fix. But if they
slipped the schedule, they'd get a rocket from further up the
food chain, so it was a no-win for them.
>
>The HEAD of the ports svn repo is for the cutting edge development, a
>quarterly branch is created every three months and is only updated to
>receive security and build or runtime fixes during that time.
>
>The quarterly ports has been setup for a couple of years but doesn't
>seem to be documented well, or it just isn't obvious to find. You can
>use svn to checkout a stable branch by specifying a branch name, such as
>ports/branches/2016Q4 instead of ports/head. You can also adjust pkg to
>use the quarterly ports by changing the pkg repo URL from
>pkg.FreeBSD.org/${ABI}/latest to pkg.FreeBSD.org/${ABI}/quarterly
That's interesting. The ones that break on me are the ones I get
from portsnap. Does portsnap tap quarterly or something else?
>I would say this rarely happens with the default setup, the more port
>options you change the more likely it is something will break.
That's WHY I avoid ports. Like Grzegorz, I don't necessarily, or
even usually, want the default options. But if my only hope is
to build the default version, why not just install the package,
if there is one --- it's what I'd get if I built the port, and
the package builder has already done all the work I'd have to do.
Perhaps The Major Problem currently is that the makefile goes and
fetches code chunks from sources that are out of our control. And
it's done fresh for *every* individual build, so J. Random Devguy
somewhere can decide on the spur of the moment to change his
chunk of code, or change where he's keeping it, and suddenly the
build breaks because of version skew or FNF.
Contrast that with how it would be if the maintainer got one copy
of every potential chunk at the beginning of the cycle and stored
it in ports so that everyone who builds the port builds against a
known-good set of bits. It would be both more stable and faster.
But that's not how it's done. Why not?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5s3t4c576qeivfr32d2j7u1fm8jkia97jf>