--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
> pain developers appear to have with keeping old or exotic=20
> ports up with architectural changes applied to MI code,=20
> such as time-counters recently (which despite of what will=20
> be said I consider a change still also useful for the=20
> ports that will be mentioned):
>=20
> If a certain port of NetBSD has proven mature and the=20
> underlying platform is not subject to changes anymore, for=20
> instance because it is discontinued vendor-wise, move(!)=20
> the MD code for it to a new branch, along with a copy of=20
> all MI code that builds and works for that platform. Try=20
> to fix remaining issues, maybe do a platform-specific=20
> release, and from then on, only pull up fixes for bugs and=20
> security flaws.

You're talking about EOLing these ports, which is not something the=20
project has decided to do.

> I think there are already numerous ports that would=20
> qualify for being handled that way. Also note that such=20
> ports aren't being degraded to "abandoned"; their state is=20
> rather uplifted to "completed, yet supported" (now _that_=20
> sounds like something I would install on my pet=20
> 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."=20
While there are some features that really will never fly on the old=20
hardware, there are a number of ones that will be useful.

> To keep this short, I won't elaborate further on this=20
> matter. I suppose the advantages and disadvantages of this=20
> approach that came to my non-developer mind immediately=20
> occur to yours as well. If it turns out that I have been=20
> missing serious points when writing this proposal, it=20
> won't hurt me much if it is ignored or flamed to the=20
> ground. (In fact, I have turned away from playing with=20

I'm not going to flame you, as there's been too much of that. And I think=
=20
you sincerely offered this suggestion to help. I just strongly dislike it.=
=20
:-)

What you describe may be a good way to handle a dead port, not a=20
limited-functionality living one. Keeping less-lively ports in-tree makes=
=20
them easier to support, actually. While some changes mean touching lots of=
=20
MD code, I think that overall things are easier as we only have one copy=20
of the MI code (with this idea we'd have one per branch). That makes=20
support a lot easier.

We also have tools, such as cscope and id-utils, to help make broad=20
sweeping changes. I've done these changes on occasion, and being able to=20
shove everying into one vi session makes it easy; load up the saved=20
buffers ('"a' though '"z' & such), and it all turns into a big multi-paste=
=20
session. Not too painful. And if it gets painful, ask for outside help.

Take care,

Bill

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFGYpsWz+3JHUci9cRAoXzAKCXuTqaYPckkDbc+wOt99grLE6BXgCdGff3
Q57pq+LlWy+Ube4F71pDc4o=
=tinq
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--