|Subject:||Re: To share or not share ? (was: Someone working on a SPARC version?)|
|From:||Pedro Giffuni (pgif...@fps.biblos.unal.edu.co)|
|Date:||Mar 18, 1997 6:25:29 pm|
Terry Lambert wrote:
We have the build process for user space which *includes* the build process for what we call "ports".
You must admit we both see external software (AKA ports) in a different way. Our ports tree is one of our strongest points and is an integral part of our nifty identity. Let's not discuss this anymore, I got your point; if they want our porting subsystem or not is irrelevant, what they don't want is our build tree.
I have also heard that, it is not 386 specific, but rather "FreeBSD specific", you're right, but I haven't heard of anyone using FreeBSD's VM under NetBSD (did you?).
Yes; I have a tape with a DEC Alpha NetBSD with Jeffrey Hsu's patches...
OK, I take my hat off (no it's not Red :-) ), this sounds interesting.
Negotiations are not what make a unification unlikely. If you were here fore the last attempt, or if the list archives archived that discussion, it's possible to find out what the sticking points were.
I'm probably not subscribed to the correct list (the "hackers" is a mailstorm with devices going one way or another). But I don't need to be a genius to see the so called unification will never occur; both parties will adopt what they need, using the other system as a reference.
You are talking about a large scale code merge and a restructuring of the build tree. I agree totally, 100%.
I find the word "merge" big for this situation (of course, I'm also finding out you think BIG). To merge you need two parts joining into one. We will "share", "copy", "adopt" some of their things, but they will not adopt our things and if they do, the resulting systems will be different. To be more specific, we want our PC devices like they are right now (or with very slight, trivial changes). It is not clear how this would change if the build tree changes. On NetBSD the devices suffered this effects so would have to face it sooner or later.
... Restructuring the build tree must occur before the code merge,..
I agree, if we try both at the same time we would end up replicating and duplicating NetBSD.
FreeBSD bystanders: notice I said *code* merge, not *group* merge; there
This is an important distinction: even if we were using the same code (like we once were) I see a group merge very distant.
So ..what goes on? Should we leave the reshuffle for 20.0-current?
Regards, Terry Lambert ter...@lambert.org
--- Any opinions in this posting are my own and not those of my present or previous employers.