Re: vendor imports beyond the committers guide?

On Tue, 5 Mar 2024, Warner Losh wrote:

> On Tue, Mar 5, 2024 at 2:46 PM Bjoern A. Zeeb <bz@freebsd.org> wrote:
>
>> Hi,
>>
>> there's the edge case when we already have code in contrib which was
>> previously directly committed and now should come out of a vendor
>> branch.
>>
>> (1) how does one properly seed that case?
>>
>
> Was it direct committed to contrib? Or somewhere else? If you are moving it
> to contrib, just follow the process in the handbook + delete the old code
> in the
> same commit as you merge the vendor branch in (so the old history will be
> available more often)...
>
> If it was direct committed to contrib, then it's a vendor import + subtree
> merge
> + maybe fixups for FreeBSD. Vendor merges are just a convenience so that
> future vendor events are constrained...
>
> These details likely need to be documented, but what's the details here that
> you need to do?

I may want to track the (unchanged) versions of the LinuxKPI based wifi drivers
in sys/contrib/dev so we can more easily diff against the latest upstream
import and ship changes back etc.


>> (2) given I couldn't see that mentioned either anywhere, for local
>> changes, they only live in main and stable/ but vendor doesn't have them
>> so in case of conflict they'll show up with the merge from vendor to
>> main and need to be resolved then?
>>
>
> stable branches don't care about vendor branches (except in some rare cares
> that almost certainly won't pop up here). You are just merging changes in
> main,
> via cherry-picking, into stable.

Right and local changes are in main and in case of conflict show up
during the merge from vendor to main and get resolved during that merge
like merge conflicts?

Sorry, may sound too stupid question but I never worked with vendor branches
in cvs/svn/or git before.

-- 
Bjoern A. Zeeb                                                     r15:7