From owner-freebsd-ports@freebsd.org Mon Dec 12 12:48:02 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EE5DC73DE4 for ; Mon, 12 Dec 2016 12:48:02 +0000 (UTC) (envelope-from scratch65535@att.net) Received: from nm25-vm1.access.bullet.mail.gq1.yahoo.com (nm25-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF5971974 for ; Mon, 12 Dec 2016 12:48:01 +0000 (UTC) (envelope-from scratch65535@att.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1481546686; bh=iknfiki9h41fQp+F+q33/Q33ps+hMSficEi4cCef50I=; h=From:To:Subject:Date:References:In-Reply-To:From:Subject; b=zwDKU9xt0gxuei/LSKagcw62DbaXtKCkkGcYX4MHPxiKlhf/Vl0w54x23yJbekp7TW9okacHwwa1/xwUMjpnS4771vCLcD4h8uIrl/zhThdX02eupB3noHMmdUyhQ6BZfSwkX4JJRXbtPdfAo5A4nTsecrpDua5CqHZOkCkrQRU= Received: from [216.39.60.176] by nm25.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Dec 2016 12:44:46 -0000 Received: from [67.195.22.117] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Dec 2016 12:44:46 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.gq1.yahoo.com with NNFMP; 12 Dec 2016 12:44:46 -0000 X-Yahoo-Newman-Id: 768893.21879.bm@smtp112.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kmHwQyoVM1lxxhtFgUJLnCK0yk5lUf1r3opAczGODhF5sal Gq4tHWjD3.q89x9pSSP8h2Tqm6J2zi1zm9nCUiOQqFfx7NSXJUN0RL5R2y3k lOvykucbraMR4aWOfKi9soXH2ROub4nIYxKQalSLTzmMJv_NxUGmmerCIrcK qWs6jEqLXmy9TDQ.1cvwqeDY4os6mxNF5b1OSeFRmK_qQnqb7pR4QFBwgJiF IAuj0iTC9fkYDthEXTOGAxwdSr8_Jkzq9LdxlnTsN017b7Jlew4hHFBqzZ6t IyVRvvSoO88Y5eE1X09Y.1n5cdw_8cjF24M47MXO62N8RIDnIZfZF8WoiYO7 5lz35ztZFRMKcMLpiPUWi7xyAFG_V4uX2LrBU2K7tyyS3RsgVxNUeREt9Lxg fwDxGfzFXFvb4z8Mk5NWBd7ib40WxiQNTav7v81RqOQEnroWrBaDJ5WMrkcL ogMNux7l8pWLsGDe8EYTJGphS_FHmzIzz_UULpPxP5R3ynQnoW0ZlTjW2Qp1 qjcc1BpjaOVlQJlHyY33XUj2RE5wt1XPvBtvpsYJCbsLw0Dp5iz1CRpS.sou l X-Yahoo-SMTP: pPvqnOaswBBbYZLVYFzvU7GaowLcbNioPp.aF8KvOjZk From: To: freebsd-ports Subject: Re: The ports collection has some serious issues Date: Mon, 12 Dec 2016 07:44:47 -0500 Message-ID: <5s3t4c576qeivfr32d2j7u1fm8jkia97jf@4ax.com> References: <20161208085926.GC2691@gmail.com> In-Reply-To: X-Mailer: Forte Agent 4.2/32.1118 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 12:48:02 -0000 [Default] On Mon, 12 Dec 2016 17:01:33 +1030, Shane Ambler 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?