On 23/06/2017 03:58, Julian Elischer wrote:
On 23/6/17 6:36 am, Miroslav Lachman wrote:
scratch65...@att.net wrote on 2017/06/23 00:15:
[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
<lini...@lonesome.com> wrote:
On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@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
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
