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
