3 ms·

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 pu

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.

toast0 7y ago
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.
- microcolonel 7y ago
  > 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?
  - busterarm 7y ago
    > 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.
    - microcolonel 7y ago
      > 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).
      - busterarm 7y ago
        How many times have you missed so far in this thread that there has been a git mirror of OpenBSD's source code for the last three years? At this point you're just flaming.
      - toast0 7y ago
        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 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.
busterarm 7y ago
This is why I don't believe you: https://www.openbsd.org/faq/faq5.html#Diff https://www.openbsd.org/faq/faq5.html#Diff 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.

toast0 7y ago

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.

microcolonel 7y ago
> 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?
- busterarm 7y ago
  > 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.
  - microcolonel 7y ago
    > 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).
    - busterarm 7y ago
      How many times have you missed so far in this thread that there has been a git mirror of OpenBSD's source code for the last three years? At this point you're just flaming.
    - toast0 7y ago
      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 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.

busterarm 7y ago

This is why I don't believe you: https://www.openbsd.org/faq/faq5.html#Diff https://www.openbsd.org/faq/faq5.html#Diff 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.