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

[Alex]

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.