On Mon, Aug 4, 2008 at 6:47 AM, <
olafBuddenhagen@gmx.net> 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.)