From owner-freebsd-stable@FreeBSD.ORG Thu Sep 4 15:41:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C11F826 for ; Thu, 4 Sep 2014 15:41:09 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 7045D1AFA for ; Thu, 4 Sep 2014 15:41:09 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-173-253-182.range86-173.btcentralplus.com [86.173.253.182]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 9935445038; Thu, 4 Sep 2014 15:34:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 9935445038 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1409844889; bh=VQh7x1/2qEO+r6c+v48rHf6i5U8pIBOnzqwFz2PzLGg=; h=Date:From:To:Subject:References:In-Reply-To; b=zDeAlWqk69hZufRnGV0P7lwx6slT8y+cq0b5SkNCwFfx2CAco6lx+svvBi9dowYFr BeAcpXpi3+xBF6SwFYffaE7MzyUsvO3U8wo8UDYfrYJeNAERBgsQBa9GU3NTXTCSDq kpdpPOiUECWxkgtwa3uOph/cJ2FJY7jq1+Wd+zUE= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id A6FED1483E; Thu, 4 Sep 2014 16:34:46 +0100 (BST) Date: Thu, 4 Sep 2014 16:34:46 +0100 From: Ben Morrow To: paul@gromit.dlib.vt.edu, freebsd-stable@freebsd.org Subject: Re: 20XXQN ports branches [was: [HEADSUP] pkg(8) is now...] Message-ID: <20140904153442.GA2004@anubis.morrow.me.uk> Mail-Followup-To: paul@gromit.dlib.vt.edu, freebsd-stable@freebsd.org References: <5405890F.8080804@freebsd.org> <20140902125256.Horde.uv31ztwymThxUZ-OYPQoBw1@webmail.df.eu> <5405AE54.60809@sorbs.net> <1D2B4A91-E76C-43A0-BE75-D926357EF1AF@gmail.com> <5405E4F5.4090902@sorbs.net> <5406BD65.705@digsys.bg> <5406ED34.7090301@sorbs.net> <5406F00C.6090504@digsys.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <358B9E99-5E02-47BA-9E30-045986150966@gromit.dlib.vt.edu> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:41:09 -0000 Quoth Paul Mather : > > Fairly recently, there was launched a "stable" ports branch. This is > updated quarterly, and seems akin to the quarterly releases of pkgsrc > in that the given branch receives only security updates after it is > created. It appears to be fairly low-key. I remember seeing an > announcement on several FreeBSD mailing lists about its initial > release, but haven't seen anything since (even though I believe it is > now in its second quarter, at least). > > My question is this: does anyone have experience of tracking ports via > these branches? Does it work well? I can see that it would be > advantageous to those wanting less frequent churn. I wonder, though, > whether it doesn't just postpone the headaches to a quarterly basis, > when the next branch is made. It would seem that all the churn would > come all at once. Some people recommend not going too long between > ports updates because there's an increasing probability something will > fail to update the longer you wait. Is a quarter just right in terms > of time? I'm tracking these branches, though not in any sort of 'enterprise' environment, just for a couple of servers and a couple of desktops. I have to say it's a huge improvement, at least with the time I have to dedicate to keeping things up-to-date: given the amount of general churn in the ports tree at the moment, I had actually taken to keeping a local stable branch of the tree in git, and cherry-picking specific ports as I needed them. (The fact that I switched from portmaster to poudriere, which insists on rebuilding everything that's changed, didn't help.) Needless to say, this was a tiresome process: I had some scripts which would take a port, find its deps, and try to cherry-pick what was needed; but it often didn't work right, and I had to just bite the bullet and merge the main ports tree in. (At which point I had lots of merging fun to deal with.) So, having someone else do this work, in a somewhat more organised manner, is a big win for me :). (Thank you, bapt@ and everyone else involved.) So far I've only gone through one rollover (Q2->Q3), and, while it took a bit of effort to merge forward my local changes and while I ended up rebuilding nearly everything, it was relatively painless. Certainly a great deal easier than having to run around chasing deps every time a security advisory came out. One thing I'm not entirely clear about, though, is the policy about what gets MFHed. I was expecting that any port with a current SA would be updated (and nothing else would), but currently I have firefox-esr, nginx-devel, serf and subversion showing advisories and they don't appear to be going to be updated in 2014Q3. Firefox, in general, puzzles me: I've had to backport FF updates several times because of advisories, and yet Chromium (say) seems to get regular MFHs. > I don't believe the "stable" ports branches are completely like the > pkgsrc quarterly releases. As far as I know, the pkgsrc quarterly > releases are a chosen subset of the regular pkgsrc rolling release > version, whereas the "stable" ports branch is a snapshot of ports at a > given time. I don't know what measures are taken to ensure that one > version of the "stable" ports branch can upgrade to the next "stable" > ports branch. Is it left as an exercise for the reader to pore through > /usr/ports/UPDATING and work out what is needed to be fixed by hand? I'm not quite sure what you mean here: yes, you still have to read UPDATING whenever a port actually gets updated. The ports tree in general goes to a lot of effort to make upgrades work in spite of occasional upstream stupidity; when this can't be done automatically, UPDATING is the only option. Ben