David Holland <dholland-tech%netbsd.org@localhost> writes: > On Thu, Mar 17, 2016 at 10:34:05PM +0000, John Klos wrote: > > There's been lots of discussion (although not here) about moving NetBSD > > from CVS to something else. There are many points to discuss, so it may be > > worth separating discussion in to one of several threads: > > > > 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. > "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. 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: how do we cherry-pick changes from -current to release branches, and how do we control when it happens 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) The other workflow aspect is handling contributions from non-committers. In CVS, we mail patches (or put them in gnats). With git or hg, the contributor can prepare a complete commit, with a commit message, and these can be handled in-tool (the first putting more work on the contributor and both less on the person handling it, a huge win) In a non-public project I work on, changes are on branches, and the branches are reviewed and tested (and then rebased to have a clean history) before being merged, which is an example of a different workflow, and one that's awkward with CVS (or svn, really) and works easily with git (and hg). We could later (and separately) discuss the notion that commits to be applied to master (HEAD, whatever) be run through a build/anita before merging, to avoid build breakage and regressions.
Attachment:
signature.asc
Description: PGP signature