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

Warner Losh imp at bsdimp.com
Tue Jul 3 14:55:19 UTC 2012


On Jul 3, 2012, at 8:50 AM, gnn at freebsd.org wrote:

> Again, moving to arch@
> 
> At Mon, 2 Jul 2012 14:09:31 -0700,
> David O'Brien wrote:
>> 
>> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote:
>>> On 06/29/2012 10:58, Pedro Giffuni wrote:
>>>> Now .. David pointed out I am not respecting the code
>>>> provenance since I didn't add them to the opensolaris
>>>> vendor area, but these files are copyrighted Joyent
>>>> Inc (not even Illumos) so I cannot put them there
>>>> unless we create a new vendor for Joyent
>>> 
>>> Creating a new vendor area would be the right solution, yes.
>> 
>> I totally disagree -- it will cause a real pain merging.
>> 
>> Think about it -- if we import a new code drop of uts/common/fs/zfs/*.c into
>> '^/vendor-sys/illumos', how do we merge that to HEAD?
>> 
>> I don't believe 'svn merge -c <GRN>' will work because we already have a
>> different uts/common/fs/zfs/*.c from ^/vendor-sys/opensolaris.
>> 
>> I think we either need to just call Illumos OpenSolaris for these
>> purposes, or 'svn move opensolaris illumos'.
>> 
>> I think this needs to be discussed with the Repo Meisters.
> 
> I actually agree with Doug here, but not strongly, I'd prefer to be
> better educated about this topic.  Do our Repo Meisters read arch@?

I agree with Doug as well.  I think that transitioning from one vendor tree to the other is the right thing to do.  Unless we have good, concrete reasons not to do this, I think the default assumption should be this is a good idea.

I believe that svn merge -c XXX will work because of how mergenotes work, but I'd appreciate confirmation from our repo masters.

I think that having the two different sources is a good thing, should OpenSolaris ever come back to live and be a viable source of imports.  We need to keep that option open, unless doing so has a real, demonstrable harm.

Warner


More information about the freebsd-arch mailing list