Subject: Re: A proposal on how to further handle ports
To: None <email@example.com, firstname.lastname@example.org>
From: Dennis den Brok <email@example.com>
Date: 09/26/2006 22:54:53
Bill Studenmund <firstname.lastname@example.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,