Date: Sun, 3 Aug 1997 15:41:30 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: tom@uniserve.com (Tom) Cc: andreas@klemm.gtn.com, chuckr@glue.umd.edu, ports@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Make this a relese coordinator decision (was Re: ports-current/packages-current discontinued) Message-ID: <199708032241.PAA02594@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.96.970803113010.3843B-100000@shell.uniserve.com> from "Tom" at Aug 3, 97 11:37:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > b) people like me, who have only one machine, usually > > run the bleeding edge, > > I don't believe this is true. I believe true number of bleeding edge > users is small. Unless your are a developer, there is little benefit. > Other than SMP, what is in current that would tempt people to use it? 95% of the FreeBSD developers doing bug fixes. What percentage of these developers are soing the same for 2.x? > People with only one machine are not normally technically advanced to > run current, because they don't have the resources to develop that > experience. This has to do with the rules used to check things into the source tree and to replicate the source tree, nier of which enforce any buildability. It also has to do with the tools; there is no graceful way one can type "make" and upgrade their system reliably. Specifically, there are issues with installed vs. run components; the libraries, the assemblers, the compiler, the ld.so, and the crt0 are main examples; look at the pain in the ass it was for the new mount system call, which required a new libc which required a new assembler for the updated assembly code for the thread call syntax changes which required ... > Key point here. Basically no one can stop developers from making > current incompatible with stable. Basically, if current developers agree > not to break compatibility, the problem goes away. This is not an answer. Making -current more stable (not more -stable) is a better try at an answer. It's not perfect, either. Tools would fill in the gaps, so at least the transitions across compatability boundries would be as painless as possible. FreeBSD should not be an Intel processor or a Microsoft OS: let others put the "backward" in "backward compatible". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708032241.PAA02594>