Hi md...@FreeBSD.org!

On Thu, 25 Aug 2011 13:59:30 -0700; md...@FreeBSD.org wrote about 'Re: FreeBSD
problems and preliminary ways to solve':

Umm, may be I was not clear. The question of trust is orthogonal to what I wanted to say. If the VCS machine is a "dictator", then any committer is trusted to commit to any part of repo, this is left as it is now. What I'm talking about is contributing. I can view a part of committer's workflow when a contributor wants to do something big. So, he has to do things in his own repo first, then make a big patch to send to his friend at freebsd.org, which will apply it and commit. Many boilerplate work.

But there will be much more work if contributor periodically updates his work. It is will be a pain to merge changes. And with DVCS all history in contributor's repo could been merged to main FreeBSD repo as well. Think about Perforce and users/ & projects/ in our SVN - that's also too much overhead for most contributors.

Suppose we have such VCS based around central repo. Because a central repo concept exists, I, as a contributor, do clone a *set of files*, neither just subtree as in SVN nor entire repository as in Git. The VCS maintains those set - sys/netinet/ipfw/*, sbin/ipfw/*, etc/rc.d/ipfw and a few files from sys/netinet/ (not all). Note those are individual files, based on a inode-like object in repo. My VCS copy set up to templates as in main tree (just like subversion-freebsd now). I do several commits to those files, the VCS automatically tracks changes from central repo to me. Then, when I'm done, those entire commit history from my branch could be imported by interested committer, not just resulting patch. Effectively an outside vendor branch, closely tied to it's native original freebsd.org, though.

Nope. More solved tasks - that is what better. And less code/smaller & cleaner code/less people/etc. - these are just a manner, a way to achieve that goal, not the goal itself. Adjective is not a noun.