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

[Matthew Seaman]

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.

  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.

Tedious and difficult generally means "you need to pay someone to do
that".  Which means you need a commercial setup to generate the money to
pay all those wages.  Which means you -- the end user -- get to pay for
the provision of those specially maintained package sets.

Now, if you think you have a viable business case for maintaining
essentially a static snapshot-plus-security-fixes of the ports and
supplying packages generated from it, by all means go ahead and try
offering that as a commercial service.  I doubt you'll succeed though --
a number of other people[*] have been down that path, and they usually
give up fairly early because the market just won't support it at the moment.

	Cheers,

	Matthew

[*] These guys most recently:
http://www.xinuos.com/menu-products/openserver-10  They're still going,
but I haven't heard of much activity from them for the last year or so.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 972 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20170622/0f7cbbcf/attachment.sig>