The cost is in opportunity. I know a number of competent developers who wanted to add something to OpenBSD (and had a good chance of succeeding), but were so put off by CVS (which is especially inconvenient if you're not already an OpenBSD maintainer) that they either stopped right there, or didn't continue after getting CVS "working". It's not that people can't use CVS, it's that nobody in their right mind would willingly suffer the personal insult of being required to use CVS, because it has basically nothing going for it, and there are so many other options.
I think this is a bit of survivorship bias: CVS is working fine for the people it works fine for, but who knows? Maybe out there somewhere, there's somebody who was put off by CVS, who would otherwise have gone on to finally update the Radeon drivers for GPUs from the last five years.
Honestly, I don't see how choice of VCS matters to outside contributors. The process is almost universally get a recent checkout, make modifications and test them, then send a patch.
Sending a patch with github seems more convenient for about the first 5 minutes, but you have to be really careful, because the pull requests aren't frozen like a patch in email would be (this could be good or bad, but it was unexpected to me)
Certainly, version control approaches make a big difference if you're committing, but to decide not to start contributing because you wouldn't like being a committer doesn't make sense to me. Chances are, you won't become a comitter.
> Honestly, I don't see how choice of VCS matters to outside contributors. The process is almost universally get a recent checkout, make modifications and test them, then send a patch.
What happens when you need to rebase? When you need to backport (or separate changesets, as may be the more common use case with OpenBSD)? Why use a tool which doesn't help you with anything and is, relatively speaking, way more complex to use than necessary?
CVS is being used effectively as rsync + changelogs, and sure, you can use git locally if you want the features, but why start with the virtually-useless format?
> What happens when you need to rebase? When you need to backport (or separate changesets, as may be the more common use case with OpenBSD)? Why use a tool which doesn't help you with anything?
I think you missed the key part of the question that was asked of you. Why would _outside contributors_ care about any of that? The process is to submit a diff via email. You don't need to do any of those things to follow that process. And there's a git mirror anyway!
> CVS is being used effectively as rsync + changelogs, and sure, you can use git locally if you want the features, but why start with the virtually-useless format?
Start with? OpenBSD started in 1995. It predates Git, Mercurial and Subversion by many years. Subversion's 1.0 release wasn't even until 2004. Their process has been working extremely well for a long time.
> Why would _outside contributors_ care about any of that?
Because not every outside contribution touches no popular code, and not every outside contribution goes directly into the upstream. Long-running external branches are common, reasonable, and easy in git; when I was trying my hand at a V8 port, I was able to keep it building against upstream V8 the whole time (2+ months, and would've been longer if I brought it to completion).
If OpenBSD's port system is anything like FreeBSD's, a v8 port to OpenBSD would have been in the ports tree, where the final product is expected to be a stub makefile that more or less is expected to download an upstream release tarball, apply some patches and then build it, right? (Like https://github.com/openbsd/ports/tree/master/lang/erlang/21 but for v8 instead)
I'm really confused how managing those patches is harder in git vs cvs? Or are you objecting to having ports as a collection of tarballs with local patches? Or were you trying to get v8 included in OpenBSD base for some reason?
Earlier in the thread, you were saying that CVS was a barrier to entry for contributing, but now you're saying you're not even sure you're planning to contribute. In that case, use the git mirror. Even if you are going to contribute, you can use the git mirror.
I was not talking about an OpenBSD package, but porting V8 to a new ISA. And yes, I have no plans of contributing to OpenBSD right now, because it works fine for the machines I can use it with, and it doesn't support my workstation hardware at all (which is what I'd be likely to contribute for).
Try to apply my patch on the relevant release branch, and carefully check that it works, or reimplement it, depending on how much changed in the area I'm patching? If it's trivial to apply to a previous release and desirable to do so, the project team is likely to do it without me.
CVS or git or SVN or tarballs or hg all do the same thing for me as an outside contributor: give me a basic tree to start from and send diffs from.
The procedure is to email diffs to the mailing list. You only really need CVS for checkout and there's been a git mirror for 3 years now. The procedure has very little friction.
I can't really speak to the intentions of the project developers, but my assumption is that more contributors or contributions themselves are not the goal. The project wants people who are extremely motivated by the project's goals.
I think this is a bit of survivorship bias: CVS is working fine for the people it works fine for, but who knows? Maybe out there somewhere, there's somebody who was put off by CVS, who would otherwise have gone on to finally update the Radeon drivers for GPUs from the last five years.