Date: Fri, 23 Jun 2017 15:47:30 +0000 From: Grzegorz Junka <list1@gjunka.com> To: freebsd-ports@freebsd.org Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version Message-ID: <5eabe1d2-85a3-f7eb-a1ab-dc5552eb70fe@gjunka.com> In-Reply-To: <09384577-ed7e-d142-43f3-0a08f5d21056@freebsd.org> References: <CAO%2BPfDeFz1JeSwU3f21Waz3nT2LTSDAvD%2B8MSPRCzgM_0pKGnA@mail.gmail.com> <20170622121856.haikphjpvr6ofxn3@ivaldir.net> <dahnkctsm1elbaqlarl8b9euouaplqk2tv@4ax.com> <20170622141644.yadxdubynuhzygcy@ivaldir.net> <4jrnkcpurfmojfdnglqg5f97sohcuv56sv@4ax.com> <20170622211126.GA6878@lonesome.com> <n8eokc5fafda8gedtvbhh7i0qdk83gur5q@4ax.com> <594C4663.5080209@quip.cz> <09384577-ed7e-d142-43f3-0a08f5d21056@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>> <linimon@lonesome.com> 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. Grzegorz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5eabe1d2-85a3-f7eb-a1ab-dc5552eb70fe>