Date: Tue, 04 Mar 2003 09:49:52 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Barcroft <mike@FreeBSD.org> Cc: Tim Robbins <tjr@freebsd.org>, freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version Message-ID: <3E64E740.9D1DC8B3@mindspring.com> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <3E64CCAB.4C70108F@mindspring.com> <20030304112249.B70629@espresso.bsdmike.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Barcroft wrote: > Terry Lambert <tlambert2@mindspring.com> writes: > > Tim Robbins wrote: > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > > it serve a purpose now that it could not serve if it was moved to the > > > Attic? > > > > Might as well move /sys/i386/conf/GENERIC to the attic while > > you are at it. It can serve it's purpose from there, too. > > This comment is not helpful. Then let me politically correct it. I am cynical about the ability of any code to serve the same purpose from the Attic which it serves in the main source tree. What of the rest of my comment, which you removed? I'll rephrase that, too: Is there a compelling reason for removing this working code to the Attic? I am cynical that any purpose is served by making this change; my cynicism leads me to believe that the intention of it is to make it easier for someone to hack up other code which uses related API's, without having to hack up the netns code as well. In other words, it is being done to avoid maintenance, so that code changes may be hurried into the source tree. This upsets me, in that it seems to me that if someone makes an API change in one place, and avoids it in another, then the person who best understands the API change will be later unavailable to correct the code in which they avoided making the change. This is because, by avoiding the change in the first place, they have expressed a disinterest in making the change in the code in question. I would feel much more comfortable, were mainting older code, rather than diking it out, made part of the cost associated with making the API change in question. In other words, in order to write new code, it is sometimes necessary to maintain old code, and that maintenance is part of the price you must pay to the project in order to have your new code accepted. If this can not be accomplished, then I would submit that the new code be documented sufficiently before the dikeing out of the older code, such that someone else may take on the task of converting the code. Further, I suggest that there be some collaboration between the person making the changes, and anyone who wants to step forward in defense of the older code, such that there is an opportunity to correct the old code before it is diked out. In other words, it seems to me that the dike out is a "first strike" attack on code which will not LINT, following changes which are currently stored in someone local source tree, and the intent here is to dike out the code, and quickly follow it up with a set of commits which will kill it. Thus preventing it from "serving it's same purpose from the Attic". Practically, and historically, it seems that there are a lot of instances, recently, of code being diked out, not because it is not currently working, but because someone wished to avoid maintaining it in the face of some sweeping change or new idea they want to push into the project. Or if you prefer an analogy: it is one thing for bits to rot; it is another thing altogether to intentionally spray them with Agent Orange. Regards, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E64E740.9D1DC8B3>