------=_Part_22389_13047792.1159324556905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I do not think this proposal is congruent with NetBSD's ideology nor its
goals.  I agree with a previous poster that deeming a port "completed yet
supported" is simply euphemistically EOL'ing it.

NetBSD can only be "finished" in the sense that someone's career is
"finished", i.e. no more work will ever be done.  Given the constant flux
intrinsic to its distributed, open model of development, portions of the
code base may lie stangnant for a while until someone comes along to develop
them, e.g. the LFS file system; these dynamics are cyclical and complex.  A
recent example of the concepts I'm highlighting is the addition of
timecounter support to each platform.  If a port is marked "completed", they
will necessarily be at least somewhat excluded from this process.  IMHO,
the current scheme of "experimental" vs. "mature" ports is well-suited to
NetBSD.

Think about it: how can a port which is complete be supported if support
entails development?  Bug fixes do not suffice on their own; at times, there
must be major rewrites.  Your notion of a "completed, yet supported" port is
commonly known as "legacy" software.  NetBSD's emphasis on elegant
portability is incompatible with categorizing some ports as "legacy";
supporting many old platforms is not merely an esoteric pursuit irrelevant
to the mainstream!  Rather, it helps to ensure coherency, scalability, and
stability.  Code which runs well on embedded systems which seem
resource-starved compared to the most modest desktop PC seems--to me**, at
least--way more likely to scale well:  Compare Windows CE running an a PDA
vs XP on the desktop, and then think of NetBSD on a PDA vs. NetBSD on the
desktop!  Windows CE is scaled down, whereas NetBSD, in most cases, simply
scales up.  Thus, having ports which are not production quality [yet]
benefits the ports which are.

Am I on target here?  I like to know if I make sense or not. ;)

--Blair


** A lot of this is simply the rumen of materials I've read combined with my
own philosophical cogitation, i.e. I am not a professional in this field.

On 9/26/06, Dennis den Brok <d.den.brok@uni-bonn.de> wrote:
>
> On Tue, 26 Sep 2006 13:15:40 -0700
>   Bill Studenmund <wrstuden@netbsd.org> wrote: A lot that
> appears plausible enough to me to make me draw back my
> suggestion. ;-)
>
> Sorry for the noise, the badly formatted e-mail, and the
> blank reply to Bill's mail (I really shouldn't be learning
> BSD 'nail' when submitting to a public list) to all
> subscribers.
>
> Best regards,
>
> Dennis den Brok
>

------=_Part_22389_13047792.1159324556905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I do not think this proposal is congruent with NetBSD's ideology nor its go=
als.&nbsp; I agree with a previous poster that deeming a port &quot;complet=
ed yet supported&quot; is simply euphemistically EOL'ing it.<br><br>NetBSD =
can only be &quot;finished&quot; in the sense that someone's career is &quo=
t;finished&quot;,=20
i.e. no more work will ever be done.&nbsp; Given the constant flux intrinsi=
c to its distributed, open model of development, portions of the code base =
may lie stangnant for a while until someone comes along to develop them, e.=
g
. the LFS file system; these dynamics are cyclical and complex.&nbsp; A rec=
ent example of the concepts I'm highlighting is the addition of timecounter=
 support to each platform.&nbsp; If a port is marked &quot;completed&quot;,=
 they will necessarily be at least somewhat excluded from this process.&nbs=
p; IMHO,&nbsp; the current scheme of &quot;experimental&quot; vs. &quot;mat=
ure&quot; ports is well-suited to NetBSD.
<br><br>Think about it: how can a port which is complete be supported if su=
pport entails development?&nbsp; Bug fixes do not suffice on their own; at =
times, there must be major rewrites.&nbsp; Your notion of a &quot;completed=
, yet supported&quot; port is commonly known as &quot;legacy&quot; software=
.&nbsp; NetBSD's emphasis on elegant portability is incompatible with categ=
orizing some ports as &quot;legacy&quot;; supporting many old platforms is =
not merely an esoteric pursuit irrelevant to the mainstream!&nbsp; Rather, =
it helps to ensure coherency, scalability, and stability.&nbsp; Code which =
runs well on embedded systems which seem resource-starved compared to the m=
ost modest desktop PC seems--to me**, at least--way more likely to scale we=
ll:&nbsp; Compare Windows CE running an a PDA vs XP on the desktop, and the=
n think of NetBSD on a PDA vs. NetBSD on the desktop!&nbsp; Windows CE is s=
caled down, whereas NetBSD, in most cases, simply scales up.&nbsp; Thus, ha=
ving ports which are not production quality [yet] benefits the ports which =
are.
<br><br>Am I on target here?&nbsp; I like to know if I make sense or not. ;=
)<br><br>--Blair<br><br><br>** A lot of this is simply the rumen of materia=
ls I've read combined with my own philosophical cogitation, i.e. I am not a=
 professional in this field.=20
<br><br><div><span class=3D"gmail_quote">On 9/26/06, <b class=3D"gmail_send=
ername">Dennis den Brok</b> &lt;<a href=3D"mailto:d.den.brok@uni-bonn.de">d=
.den.brok@uni-bonn.de</a>&gt; wrote:</span><blockquote class=3D"gmail_quote=
" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0=
.8ex; padding-left: 1ex;">
On Tue, 26 Sep 2006 13:15:40 -0700<br>&nbsp;&nbsp;Bill Studenmund &lt;<a hr=
ef=3D"mailto:wrstuden@netbsd.org">wrstuden@netbsd.org</a>&gt; wrote: A lot =
that<br>appears plausible enough to me to make me draw back my<br>suggestio=
n. ;-)<br>
<br>Sorry for the noise, the badly formatted e-mail, and the<br>blank reply=
 to Bill's mail (I really shouldn't be learning<br>BSD 'nail' when submitti=
ng to a public list) to all<br>subscribers.<br><br>Best regards,<br><br>
Dennis den Brok<br></blockquote></div><br>

------=_Part_22389_13047792.1159324556905--