Date: Mon, 4 Aug 1997 08:26:36 -0500 From: Richard Wackerbarth <rkw@dataplex.net> To: torstenb@onizuka.tb.9715.org (Torsten Blum) Cc: asami@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: ports-current/packages-current discontinued Message-ID: <l03110704b00b7e217438@[208.2.87.4]> In-Reply-To: <m0wvLno-0006FEC@onizuka.tb.9715.org> References: <2847.870634281@time.cdrom.com> from "Jordan K. Hubbard" at "Aug 3, 97 11:51:21 am"
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:59 AM -0500 8/4/97, Torsten Blum wrote:
>Well, most of us who run -current are capable of building their own
>ports and packages.
>Well, as I said before, you can not change all ports to the "changes
>between -current and the upcoming release". That is what I call insane.
>I know this is likely to cause a "flame war", but ignoring the problem
>does not solve it...
I've kept quiet on this until now. However, I think the change IS the
correct decision.
(1) The Post-Release systems are the ones used by a majority of the users.
(2) The -current system is too unstable. The porters are having to make
changes because they are tracking a changing source AND because they
have a moving target. By making their designated target the "-stable"
branch, they have removed one of the sources of incompatability that
they need to work around.
(3) There is nothing to say that they won't incorporate changes to make
something work with "-current".
Who knows, by freeing the porters from the RESPONSIBILITY of tracking
"-current", they are likely to actually (a) get additional help from
those who "have to" run a developmental grade system and (b) waste
less time changing the changes.
Under those circumstances, I think that you might be surprised how many
ports will actually be available to the "-current" community.
Further, I think that this change shows a maturing of the FreeBSD system.
It is slowly transforming from a toy for OS hackers into a truly usable
OS for a wider audience. I think the pressures to ship a new version
every few months have limited the opportunity to have well though out,
implemented, and tested major features added.
"Evolution, not revolution" only goes so far. Eventually you need to take
the shackles off and allow significant leaps rather than just shuffling
along. Once they freeze the kernel features, we should take the time to
make the ports will work before we release it. If that delays the release
cycle (it will), then the extra time should be added to the schedule now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03110704b00b7e217438>