svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c...

[David O'Brien]

On Mon, Jul 02, 2012 at 04:10:26PM -0700, Pedro Giffuni wrote:
> --- Lun 2/7/12, David O'Brien <obrien at freebsd.org> ha scritto:
> I tend to agree with the Illumos community on that however
> we may still be seeing some movement in that area. Oracle
> has a linux distribution and commercial interests are
> always strong in unpredicable ways.
> 
> Oracle has been porting Dtrace to Linux. Apparently they
> will be adopting dual GPLv2/CDDL for some few kernel
> stuff and CDDL only for the main code, but just the same
> there may be some stuff we want to take from them.

That may be the case -- but what is the likelihood there would be code
from that effort we would want?  Vs. the real brain-share of DTrace
which commits into Illumos?  Isn't it much more likely we would want
their innovations?


> > It may be conceptually cleaner to import into
> > '^/vendor{,-sys}/illumos', but I believe that will cause
> > issues with importing updates to existing files
> > (e.g., r237458) as the 'svn merge'
> > from '^/vendor{,-sys}' will get messy.  I believe we
> > may have to resort
> > to a three-way merge using "--ignore-ancestry" -- something
> > I don't believe we want to do.
> 
> I think Martin Matuska did exactly the right thing:
> he created the illumos vendor branch starting from
> the opensolaris branch.

I don't disagree in principle, but I feel it should have been an
'svn rename' not 'svn copy'.

You didn't suggest or comment on the SCM operations having two
"vendors" puts us in.  I don't think you can make precise statements
about an illumos vendor branch without considering those.


> Concerning ZFS: the main developer of the encryption stuff
> did stay at Oracle. At this time that code will not be seen
> in the open (apparently there was a Solaris 11 source leak
> but that's not something we can touch), but we just never
> know.

We can always figure out something *if* it comes to pass that
there is a code drop from Oracle that we want to consume.

I believe the question which code base are we *most likely*
to pull technology from.  The proof to date in an 'svn log'
of our repo is Illumos.

 
> > Doesn't this commit of yours which brought in new DTrace
> > work by Joyent
> > (likely Brendan Gregg or Bryan Cantrill) show this point?
> > 
> > Perhaps we should do an 'svn move' of
> > '^/vendor{,-sys}/opensolaris'
> > to '^/vendor{,-sys}/illumos'?
> 
> Illumos is a fork so svn copy works just fine for this, plus
> copying is a very cheap operation in SVN.

That misses my point.  Yes, copying is a very cheap operation in SVN.
(so is 'svn rename')

The issue is should we have _two_ vendors that we are attempting to
merge into the same files within HEAD?

-- 
-- David  (obrien at FreeBSD.org)