Date: Fri, 23 Jun 2017 13:22:16 +0800 From: Julian Elischer <julian@freebsd.org> To: Mark Linimon <linimon@lonesome.com> Cc: freebsd-ports@freebsd.org Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version Message-ID: <3a428572-039c-79ed-8804-41e5fef4df99@freebsd.org> In-Reply-To: <20170623043947.GA8922@lonesome.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> <20170623043947.GA8922@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23/6/17 12:39 pm, Mark Linimon wrote: > On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote: >> 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. > And how much is that worth to you and/or your company? glad you asked. If we had such a setup it would probably be worth a good part of a person's salary. Since we have had to do without it, we have workarounds in place that took a lot of work to make. But we are now running a parallel system where we are taking snapshots of head and using them. The downside is that we don't have the resources to follow all the Security issues so we are forced to do cross-revision upgrades sometimes where for example all the packages we install were compiled from a tree that approximates 10.3 ports, but the openssl package is from a source tree that is much newer. We enjoy this about as much as having our corporate wisdom teeth pulled out but it's forced on us. In the near future we will be taking a new snapshot for the next release. What branch and revision of the ports tree wil be snapshotted is still not decided, If there were a suitable first-half-2017 stable branch we'd take that for sure, then we'd follow it, merging changes in, and probably feeding fixes back. Since there are no "security patch only" branches, What we will probably end up doing is snapshotting head and crossing our fingers hoping that we notice any relevant vulnerabilities and have the time to work out a fix. Of course If there is no easy patch, we may have to do single-package upgrades, which is usually only painless for a short time after the snapshot, because the Makefile infrastructure keeps changing. > > I mean, honestly. You constantly criticize the volunteers for not doing > what you need. Well _need_, to me, implies the existence of some kind > of incentive. I can state to you, flatly, that "a feeling of a job well > done" isn't _sufficient incentive_ to do professional-level QA. There's > a reason people get _paid to do it_: it's hard, long, tedious, unrewarding > work, and it never ends. > > Clearly, relying on _volunteers_ to do professional-level QA isn't working > out for you. > > Thus, IMVVHO, at this point, to get what you _need_, you need to get out > your checkbook and provide a _financial_ incentive. In my experience, > with the volunteers that we have, we can barely keep things afloat as > it is. It's sufficiently hard to recruit people, and burnout is high > -- especially given the grief we take. > > (I won't even start on how even "critical fixes" can drag in the need > to update dependencies, which then conflict with each other, and so on > and so forth, and thus even "critical fixes" aren't trivial.) > > Summary: you are providing negative incentive to the ports crew, with > no upside for them, and you can't understand why it doesn't work. > > tl;dr: you want us to be RedHat but with no paid employees. > > mcl >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a428572-039c-79ed-8804-41e5fef4df99>