Date: Sat, 24 Jun 2017 01:24:03 +0800 From: Julian Elischer <julian@freebsd.org> To: Grzegorz Junka <list1@gjunka.com>, freebsd-ports@freebsd.org Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version Message-ID: <fa33d0e8-67cb-ab06-9a58-26dafe250f6c@freebsd.org> In-Reply-To: <5eabe1d2-85a3-f7eb-a1ab-dc5552eb70fe@gjunka.com> 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> <5eabe1d2-85a3-f7eb-a1ab-dc5552eb70fe@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>>> <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. 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fa33d0e8-67cb-ab06-9a58-26dafe250f6c>