Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Mar 1997 18:25:49 -0800
From:      Pedro Giffuni <pgiffuni@fps.biblos.unal.edu.co>
To:        Terry Lambert <terry@lambert.org>
Cc:        jb@cimlogic.com.au, srn@flibble.psrg.cs.usyd.edu.au, freebsd-platforms@freebsd.org
Subject:   Re: To share or not share ? (was: Someone working on a SPARC version?)
Message-ID:  <332F4EAD.3A87@fps.biblos.unal.edu.co>
References:  <199703181746.KAA09797@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

Pedro.

> 
>                                         Regards,
>                                         Terry Lambert
>                                         terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?332F4EAD.3A87>