Bill Studenmund <wrstuden@netbsd.org> wrote:

> On Tue, Sep 26, 2006 at 10:09:25AM +0200, Dennis den Brok wrote:
> > 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.
>
> You're talking about EOLing these ports, which is not something the 
> project has decided to do.
>
> > 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 
> > hardware!).
>
> You've used very pretty terminology, however it's still EOL'ing. :-)
>
> As long as we are a living, changing OS, we will never be "complete." 
> While there are some features that really will never fly on the old 
> hardware, there are a number of ones that will be useful.
>
> > 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 
>
> I'm not going to flame you, as there's been too much of that. And I think 
> you sincerely offered this suggestion to help. I just strongly dislike it. 
> :-)
>
> What you describe may be a good way to handle a dead port, not a 
> limited-functionality living one. Keeping less-lively ports in-tree makes 
> them easier to support, actually. While some changes mean touching lots of 
> MD code, I think that overall things are easier as we only have one copy 
> of the MI code (with this idea we'd have one per branch). That makes 
> support a lot easier.
>
> We also have tools, such as cscope and id-utils, to help make broad 
> sweeping changes. I've done these changes on occasion, and being able to 
> shove everying into one vi session makes it easy; load up the saved 
> buffers ('"a' though '"z' & such), and it all turns into a big multi-paste 
> session. Not too painful. And if it gets painful, ask for outside help.
>
> Take care,
>
> Bill
q