Re: Moving NetBSD from CVS to svn|git|hg|fossil

[David Holland <dholland-tech%netbsd.org@localhost>]

(raking this up, it's not *that* old yet)
On Fri, Mar 18, 2016 at 10:57:51AM -0400, Greg Troxel wrote:
 > > > Discussion of the impact on the workflow of the NetBSD project.
 > >
 > > There doesn't have to be any:
 > >    http://www.netbsd.org/~dholland/notes/hg-migration/usage.html
 > 
 > Agreed that with git or hg it is straightforward to map existing
 > practices.

Right.

 > > "workflows" are mostly a git thing caused by git's gratuitous moving
 > > parts.
 > 
 > That's untrue.  workflow is a word that describes things like whether
 > changes are tested before being applied to the definitive copy, when we
 > create release branches and tags, and essentially how pullups are done.
 > We have a way of doing that now which works with CVS, and I see no
 > reason that can't work straightforwardly with most other tools.

Yes, except we already have existing practices for all these things,
none of which are inherently affected by a change of infrastructure.
Tying changes of long-established standard practice to an
infrastructure change is not a good idea: it will cause problems from
the procedure changes to look like problems with the new
infrastructure, and also create unnecessary resistance to the
infrastructure change.

 > The fair part of your comment is that git culture has spawned a lot of
 > "workflow" blog posts, some of which amount to arguing about which name
 > should be used for which branch (in our context, whether 'master' is a
 > release branch or -current).   These arguments are distractions; the
 > real issues (which NetBSD has established practices) are:

It's not just that; git has a lot of gratuitous moving parts and so
when using git one has to pay a lot of gratuitous attention to how to
manipulate the working parts. That is, IME, what 95%+ of git
"workflow" talk is about.

Anyway, there's only one reasonable way to approach the issues you
cite:

 >   how do we cherry-pick changes from -current to release branches, and
 >   how do we control when it happens

Use the native cherry-pick functionality, done by member of releng
according to standard procedures. Some of the details of the process
can probably be improved because the native cherry-pick will be
storing/handling more metadata than CVS does.

(However, none of the existing options store enough metadata that
releng doesn't still have to handle some of its own. If someone gets
around to writing bs(1) that might change.)

 >   how do we control whether things that appear on HEAD/master/trunk have
 >   to build and work (we don't, except for in-arrears pressure)

There are reasons (that have nothing to do with limitations of CVS)
that we don't do any more along these lines than we currently do.
Nothing in a SCM migration changes those reasons.

 > The other workflow aspect is handling contributions from non-committers.

Given that none of the currently available options has a workable
scheme for handling changeset provenance, to begin with we cannot
safely do anything other than only allow developers to push their own
changesets. That way we know that if the changeset says "christos" it
came from Christos and not from some random bozo who thought it would
be fun to commit a backdoor and sneak it in by hiding it among a pile
of other changesets.

We can think about relaxing this once we have more experience with the
tool and the circumstances.

I agree it would be highly desirable to be able to merge changesets
posted by random passersby, provided they've been reviewed. (One
further problem is that if you make it too easy to pull things in,
they won't always get adequately reviewed.)

However, the mechanism for doing so has to create a spoofing-resistant
reference chain back to the person whom the changesets originally came
from. This is not a trivial problem. While git does have some limited
scheme for this, as of the last time I looked at it it pretty much
didn't really work. (I forget the details why.) Also, just saying
"signing" is begging the question -- that's how to get a scheme that
doesn't work.

-- 
David A. Holland
dholland%netbsd.org@localhost