vendor branch updating [was "mini roadmap" for userland for 3.7-dev branch]

[John Marino]

On 11/22/2013 11:41, Alex wrote:
> On 11/21/2013 12:31 PM, John Marino wrote:
>> On 11/21/2013 12:12, Alex wrote:
>>> Thank you for this roadmap. As a newcomer wanting to contribute, it
>>> really helps with an overview of what could be done.
>>>
>>> I'll give a try on the bmake update if that's OK :)
>>>
>>> Alex.
>>>
>> Sure.
>> Vendor branching updating is a bit tricky and requires additional
>> knowledge about git.  There is good information in "man 7 development"
>> on the topic.
>>
>> Basically a filtered, unchanged set of files goes into the vendor
>> branch.  Later the vendor branch is merged into the master branch.  Any
>> "local modifications" to vendor files are applied at the master branch
>> level.  If one is lucky, previous modifications auto-merge when this
>> happens but it's possible to get conflicts that have to be resolved.
>>
>> The files that are filtered out are listed in
>> /usr/src/contrib/<some-src>/README.DELETED.  Information about the
>> source put into the vendor branch is beside it in README.DRAGONFLY.
>>
>> Generated files (e.g. config.h, man pages, etc) are put where the
>> makefiles that build the software are located (e.g.
>> /usr/src/gnu/bin/<some-name>)
>>
>> The best way to update a vendor branch is first pull the entire
>> dragonfly history (not shallow), track the vendor branch, and then go
>> through the entire motion of switching to vendor branch, committing to
>> it, switching back to master branch, creating a working branch, switch
>> to that, merge in vendor branch (resolving conflicts as necessary), then
>> adding your changes.
>>
>> When done with all commits, "git format-patch master" should provide the
>> full set of patches needed.  Note that the first patch would be applied
>> to the vendor branch by the dragonfly committer and that any "conflict
>> resolves" won't show in the patches.  Due to that feature, I've actually
>> reverted local modification patches in a commit, then merged vendor
>> branch in order to get a clean merge, then reapplied local modifications
>> in a new commit in order to capture what was really happening in patches.
>>
>> I don't want to scare anybody, but rather let them know what they are
>> actually volunteering for.  :)
>>
>> John
> 
> Thank you for your insight on vendor branch updating and development(7)
> reference. I've tryied my best to follow the workflow you described and
> successfully updated to the latest bmake (see submit #2606 on the bug
> tracker - http://bugs.dragonflybsd.org/issues/2606).
> 
> The only "real" patch we had has been merged. The state is now a few
> "cosmetics" patches that we need because we're building with stricter
> flags than upstream. One of them though revealed that we could improve
> sysctl(3) (using const arguments where appropriate) and I've already
> made up a patch that I'll submit after more testing.
> 
> I did test the new bmake by building and installing both world and
> kernel (x86_64). I also did a quick install of vim-lite to test building
> a port. Additionals tests and comments are welcome.
> 
> Alex.

Yes, it was a valiant first attempt!
I've already commented on the bug report.  Going from only the patch
file titles, I suspect several patches could and should be "flattened"
(merged together into a single patch).

Obviously I could do this manually by using "git apply" instead of "git
am" on some of the patches and editing the commit message as necessary.
 At first glance it seems that you followed the process correctly.  I'll
try to get this into base early this weekend.  Feel free to provide
updated patches if you have time before saturday to create them.

Thanks for the contribution!
John