svn commit: r337936 - in head/sys/contrib/libsodium: . builds builds/msvc builds/msvc/build builds/msvc/properties builds/msvc/vs2010 builds/msvc/vs2010/libsodium builds/msvc/vs2012 builds/msvc/vs2...

[Warner Losh]

On Fri, Aug 17, 2018 at 10:12 AM, Conrad Meyer <cem at freebsd.org> wrote:

> Hi John,
>
> On Thu, Aug 16, 2018 at 11:26 PM, John Baldwin <jhb at freebsd.org> wrote:
> > On 8/17/18 1:23 AM, Conrad Meyer wrote:
> >> Author: cem
> >> Date: Fri Aug 17 00:23:50 2018
> >> New Revision: 337936
> >> URL: https://svnweb.freebsd.org/changeset/base/337936
> >>
> >> Log:
> >>   Bring in libsodium to sys/contrib
> >> ...
> >
> > Can you import this into the vendor area and then do a bootstrap of
> > mergeinfo to sys/contrib?
>
> To what benefit?  Our vendor process doubles or triples the work
> required to update vanilla 3rd party sources like this.


Unmodified imports are literally two additional svn commands, which hardly
is a burden.

> This permits future updates to use svn to
> > merge instead of doing it by hand.
>
> What merge?  Simply svn delete the directory, copy in the new one, svn
> add it, and commit.
>
> svn merges may be helpful if we plan on carrying a diff, but we don't
> today, I do not plan to, and I hope we can avoid doing so.


Hope. The history of the project that has imported upstream stuff in the
hope it never gets modified is littered with examples where it does.

> It also permits future imports to
> > be done by other developers following our standard, documented process
> > for working with third-party code.
>
> As-is, future imports can be done by other developers without having
> to reference a document and perform 3 different SVN commits.  Just
> drop it in and go.
>
> If someone wants to figure out the vendor glue to have that match
> this, great, but I'm not really seeing the benefit.
>

This really isn't a 'playing nice with other' sort of answer. I don't think
it's within the cultural norms of the project.You should reconsider this
hostile attitude.

Warner