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...

gnn at freebsd.org gnn at freebsd.org
Tue Jul 3 14:46:54 UTC 2012


FYI I moved this to arch@

At Mon, 2 Jul 2012 22:11:35 -0700,
David O'Brien wrote:
> 
> 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?

I think that for now a dual tree approach is OK.  An extra vendor
directory doesn't cost us anything.  If opensolaris is ever truly dead
to us we can cut the dead branch from our tree.

> > 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.

I'm wondering what you're thinking here.  I'm not a whiz with our
current SCM and I will be dealing with both of these trees so I'd like
to know what you're thinking.  Also, I am hoping that in the illumos
tree we can clean up a few of the things that many people don't like
about our opensolaris tree.

> > 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?

I think that if we can get the illumos tree in shape for 10.x then
that will be the main vendor that we draw from, with bugs fixes that
wind up in opensolaris as the second ran.  I don't see any reason not
to draw from both communities, if we can.  

Best,
George


More information about the freebsd-arch mailing list