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

[Julian Elischer]

On 22/6/17 11:50 pm, scratch65535 at att.net wrote:
> [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
> justfied.
>
> 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

I've had this conversation with ports several times, But the requirements
of  'business' is not their interest.  In fact i was told several times,
"Don't use our quarterly packages, make your own with poudriere".
(which makes one wonder "What is the purpose of he quarterlies?)

My suggestion is to ignore the existence of the quarterly snapshots as
they are neither stable (they change every 3 months out from under 
you) nor snapshots,
(they a re updated randomly a bit at a time. This just doesn't work 
for what business needs.
So the only alternative is to have a SVN mirror, and take your own 
snapshots, and keep your eye
on the security notices.

>
> 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
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>
>