4 ms·

Something can be harmful to the project without totally sinking it. "Disease may be 'bad,' but it's clearly working for humans and the population continues to s

Something can be harmful to the project without totally sinking it. "Disease may be 'bad,' but it's clearly working for humans and the population continues to skyrocket exponentially like clockwork."

busterarm 7y ago
Where is the proof that CVS is harming OpenBSD? As far as I know there is none. People talk about moving it to git like there is no cost to doing so and that it will provide only benefits, but as far as I've seen there's been very little justification that's a motivation more than maintaining the status quo. I mean, I personally prefer git. I've used it at work for years and I'm quite good at it. If the project is hitting its targets while on CVS, I think that's fine.
- microcolonel 7y ago
  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
  - 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.

Something can be harmful to the project without totally sinking it. "Disease may be 'bad,' but it's clearly working for humans and the population continues to skyrocket exponentially like clockwork."

busterarm 7y ago

Where is the proof that CVS is harming OpenBSD? As far as I know there is none. People talk about moving it to git like there is no cost to doing so and that it will provide only benefits, but as far as I've seen there's been very little justification that's a motivation more than maintaining the status quo. I mean, I personally prefer git. I've used it at work for years and I'm quite good at it. If the project is hitting its targets while on CVS, I think that's fine.

microcolonel 7y ago
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
- 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.