From owner-freebsd-ports@freebsd.org Fri Jun 23 17:24:15 2017 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 46965DA8D41 for ; Fri, 23 Jun 2017 17:24:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1769C68C6D for ; Fri, 23 Jun 2017 17:24:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-108-84.dyn.iinet.net.au [124.148.108.84]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v5NHO90a065830 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 23 Jun 2017 10:24:12 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version To: Grzegorz Junka , freebsd-ports@freebsd.org References: <20170622121856.haikphjpvr6ofxn3@ivaldir.net> <20170622141644.yadxdubynuhzygcy@ivaldir.net> <4jrnkcpurfmojfdnglqg5f97sohcuv56sv@4ax.com> <20170622211126.GA6878@lonesome.com> <594C4663.5080209@quip.cz> <09384577-ed7e-d142-43f3-0a08f5d21056@freebsd.org> <5eabe1d2-85a3-f7eb-a1ab-dc5552eb70fe@gjunka.com> From: Julian Elischer Message-ID: Date: Sat, 24 Jun 2017 01:24:03 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <5eabe1d2-85a3-f7eb-a1ab-dc5552eb70fe@gjunka.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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: Fri, 23 Jun 2017 17:24:15 -0000 On 23/6/17 11:47 pm, Grzegorz Junka wrote: > > On 23/06/2017 03:58, Julian Elischer wrote: >> On 23/6/17 6:36 am, Miroslav Lachman wrote: >>> scratch65535@att.net wrote on 2017/06/23 00:15: >>>> [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon >>>> wrote: >>>> >>>>> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65535@att.net >>>>> wrote: >>>>>> My problem is that my industry experience tells me that reducing >>>>>> the frequency of port releases is practically *guaranteed* to be >>>>>> a Really Good Thing for everyone. >>>>> >>>>> I remember before we had the quarterly releases, and people on the >>>>> mailing lists complained constantly about the ports bits only being >>>>> available once per release, or rolling with -head. >>>> >>>> Mark, I can only suppose that those complainers are dilettantes >>>> of some sort who believe that having The Latest-And-Greatest Bits >>>> is a social-status enhancer. **Nobody** with real work to do >>>> ever willingly fools away time "fixing" what isn't broken. >>> >>> And this is where you are so wrong. Ports tree is never in the >>> state where everything works and has no bugs. (and cannot be, >>> because upstreams have bugs) Even if it compiles and installs it >>> does not mean that it is not broken and nobody needs newer version. >>> Just because your needs are different than others doesn't mean >>> others are dilettantes. >> >> The usage of the word dilettante can have negative connotations but >> he is in essential facts correct. >> >> I have spent 30 years on BSD systems in industry, and we almost >> NEVER want the latest and greatest (except at project start time). >> What we want is: >> A "recent" starting point for our next project/upgrade to start from >> and an ongoing version of that, which will get critical fixes only >> for at LEAST 2 years, probably 5. >> The key here is the *_*critical fixes only*_* part. >> >> We do NOT want: >> A new version of perl, python, ssh, shell openssl (*), apache, >> named, etc. etc. >> The less changes the better. Basically if it doesn't have a CVE >> number or it isn't actually completely broken, >> then don't upgrade it in that branch. >> We'll fix it ourselves if we need it bad enough (and feed back >> changes if we know it would be taken). >> >> (*) From my experience, the best way to cope with openssl is to >> have everything link with >> the system openssl and issue security upgrades to the base OS that >> upgrades that when there is a need. >> (this may change, but it's been my experience so far). >> >> The recent starting point doesn't even need to be 100.00% working. >> What we will do here is mirror it and from the mirror, put it into >> our own source control branch/tree where we will add our own >> changes to fix/tailor what we need. >> We will then keep merging in fixes from upstream. which usually >> will not collide with our private changes/fixes. >> From that we generate our required packages. >> From our perspective, a yearly branch (6 months would be 'ideal' >> but 12 would work) that gets only *critical *fixes would be wonderful. >> Remember that from the time when a product major release is planned >> to when it comes out is usually 6 to 12 months lead time. >> So when it hits the customer's racks, the packages were usually >> generated somewhere mid-cycle and are already 6 months old. >> We will not be replacing them on the customer premises machine >> until they elect to do/purchase an upgrade / patch release. >> which may be in a year or two. Certainly for a minor update it is >> rarely less than 6 months. >> It'd have to be a heartbleed scale security issue to get customers >> to do an upgrade earlier. > > Can't you just create the branch yourself? It's open source. You > just clone it and can keep it in Github for free. Then you can apply > security patches to just the applications you need yourself. If it's > too difficult you can hire people to apply just specific patches. > With Github pull requests it's deadly easy. I am sure that if you > asked maintainers to do the patching for a financial incentive they > would mind doing it. I actually explained it.. We do not have the people who understand all those ports. if there is a port hat gets a fix, one assumes there is a maintainer who at least understands that port a bit. I would feel more comfortable if they made the fix. Having said that I do think tat we do need to pony up some cash at some stage.. and many others should too if we want to have something like this. I've said this elsewhere. > > Grzegorz > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "freebsd-ports-unsubscribe@freebsd.org" >