[RFC] Why FreeBSD ports should have branches by OS version

scratch65535 at att.net scratch65535 at att.net
Thu Jun 22 15:53:45 UTC 2017

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
<matthew at FreeBSD.org> wrote:

>On 2017/06/22 15:03, scratch65535 at att.net wrote:
>> Why don't the same choices apply here?  What am I missing?
>Two things:
>  1) It's progress in the development of the FreeBSD base system that
>drives the release cycle.  The general state of the ports does not exert
>much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.    How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?

So where's the point in everyone going mad trying to keep up a
quarterly release schedule that serves more as an annoyance than
benefit to your customer base?  (Do you read the Asterix comics?
The one where Asterix and Obelix go to Switzerland is
particularly apropos here, I think:  the owner of the inn awakens
the guests every hour so that they can turn over the hourglass
mounted over their bed.  What benefit do the guests derive from
that?  None, of course, but it helps the owner feel in control of
things.  But the guests are, reasonably, quite upset by the loss
of sleep due to his obsessiveness.)

>  2) Even if we could scrape up enough people to support however many
>branches you are proposing, remember they are all volunteers.  It's hard
>enough getting people to maintain the existing quarterly branches as it
>is, and those are relatively short lived so that most merges from head
>are pretty trivial.  People really aren't going to want to do
>essentially repetitive merges to branches where everything else is up to
>X years older than head.  Which would make it both tedious and
>frequently difficult to do.

Again I'm really not following your logic.   There are 2 versions
of the base system now in play:  10.3 and 11.0.  There are 2 more
being developed: 10.4 and 11.1.   10.2 has already been trashed,
thus forcing us to upgrade to 10.3 whether we wanted to or not,
which in many cases, mine among them, was a "not".  I'm sure the
same thing will happen with 10.4 and 11.1 and plenty folk will be
just as annoyed as we were with 10.2

Let's say you guys don't try to follow that schedule.  You do a
ports release for (let's say) 10.0 and then 11.0, but not for the
other point releases in between.  So if someone feels the deep
need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis),
they'll run 10.0 (or 11.0)  ports under it.   It's done all the
time in industry.   If you treat each ports release as a DVD
--immutable once shipped--, or as a PROM, where changes can be
made but it's a pain in the dupa so you only do it for the
emergency case, it seems to me that the pressure has gone down by
a factor of  3 or so.  So where's the problem in that? 

's mise le meas

More information about the freebsd-ports mailing list