[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman <matt...@freebsd.org> wrote:
>On 2017/06/22 15:03, scratch65...@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 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
