Subject: A proposal on how to further handle ports
To: None <,>
From: Dennis den Brok <>
List: tech-kern
Date: 09/26/2006 10:09:25
Maybe one could do the following in order to reduce the 
pain developers appear to have with keeping old or exotic 
ports up with architectural changes applied to MI code, 
such as time-counters recently (which despite of what will 
be said I consider a change still also useful for the 
ports that will be mentioned):

If a certain port of NetBSD has proven mature and the 
underlying platform is not subject to changes anymore, for 
instance because it is discontinued vendor-wise, move(!) 
the MD code for it to a new branch, along with a copy of 
all MI code that builds and works for that platform. Try 
to fix remaining issues, maybe do a platform-specific 
release, and from then on, only pull up fixes for bugs and 
security flaws.

I think there are already numerous ports that would 
qualify for being handled that way. Also note that such 
ports aren't being degraded to "abandoned"; their state is 
rather uplifted to "completed, yet supported" (now _that_ 
sounds like something I would install on my pet 

To keep this short, I won't elaborate further on this 
matter. I suppose the advantages and disadvantages of this 
approach that came to my non-developer mind immediately 
occur to yours as well. If it turns out that I have been 
missing serious points when writing this proposal, it 
won't hurt me much if it is ignored or flamed to the 
ground. (In fact, I have turned away from playing with 
hard- and software and am happily running NetBSD as the 
only OS on the only computer in my tiny home ever since, 
thus don't care much about further changes to NetBSD as I 
don't intend to change running systems anymore. I just 
enjoy tracking NetBSD's development via mailing-lists, 
and, in this case, felt like contributing an idea to what 
read like a rather important issue.)

Best regards,

Dennis den Brok