Hi Thomas, antrik On Mon, Aug 4, 2008 at 6:47 AM, <[EMAIL PROTECTED]> wrote:
> Hi, > > On Sat, Aug 02, 2008 at 07:12:25PM +0200, Thomas Schwinge wrote: > > > I'd say it should clearly reside in an external module, on its own. As > > it is a stand-alone thing, a separate translator. > > The same could be said about all or most of the other translators > presently in the Hurd source tree... > > I don't really have a strong opinion on making the Hurd build (and > repository) more modular in general, or keeping it as is. But as long as > it is like now, it's not acceptable to ban some components to different > modules, while others are part of the Hurd itself. This inevitably would > mean that those outside the main tree will be second class citizens -- > less maintaining, less visibility, no inclusion in Debian, more > reluctance by users and develorpos to use them or rely on them... > > Really, there is no reason for the new code to be treated as second > class citizens, just because it happens to come later than some other > code. > > And if you are tempted to argue against this on any kind of theoretic > grounds, just take a look at the real (and unchanging) situation with > hurdextras. > > The code produced here is too valuable to end up like this. > I seriously did not know these were the reasons to keep a translator within or outside the Hurd main source tree. I had thought if it was a translator and the code is copyrighted to FSF it will go into Hurd Main Source tree. If someone chooses to hold the Copyright to himself it will be kept outside main Hurd source probably at hurd extras. Thanks antrik for helping me out to know why this should actually go into Hurd main tree. But I have no preferences. It is as Hurd admins (Thomas and all) wish. I am happy where ever it is as long as the work is useful in some way. (Hope Google's investment of 5000$ (for free software) on me doesn't go waste.) -- Thanks and regards, Madhusudan.C.S Blogs at: www.madhusudancs.info
