6 ms·

Interesting that they seem to use CVS as the canonical source control repo. I wonder what the workflows of the dev team look like and if that tool makes it hard

Interesting that they seem to use CVS as the canonical source control repo. I wonder what the workflows of the dev team look like and if that tool makes it harder for external contributors to contribute?

geocar 8y ago
> and if that tool makes it harder for external contributors to contribute? I hope so! OpenSSH is a critical piece of infrastructure in most unix and linux environments, so making sure external contributors do some extra diligence seems like a good thing!
- brylie 8y ago
  It may be important not to confuse "diligence" for "encumbrance".
- sneak 8y ago
  The willingness to jump through outmoded and unnecessary hoops does not correlate to the quality of one's cryptographic code. In fact, many who are deliberately diligent will shy away from teams who care more about tradition than quality, in my experience.
- geofft 8y ago
  Learning CVS is not "diligence." If anything, it takes up mental space you could be using on things like remembering to bounds-check your array accesses. Asking contributors to learn CVS as a quality gate is like having a tech interview process that requires beating the hiring manager at chess. Sure, you're looking for smart people, and sure, people good at chess are usually smart, but the correlation is so low you'll lose out on good candidates and get candidates who are better at chess than coding.
  - djmdjm 8y ago
    We don't ask anyone to learn CVS. People send the maintainers (myself and other) their changes (git format-patch is fine) and we integrate them.
    - geofft 8y ago
      Yeah, to be clear I think you the OpenSSH maintainers are quite responsive to people who aren't using CVS (in particular, thank you for digging into https://bugzilla.mindrot.org/show_bug.cgi?id=2863 https://bugzilla.mindrot.org/show_bug.cgi?id=2863 which didn't even have a patch!). I just want to be clear that people who look at what you're doing and say "OpenSSH is using an obscure process, that's what makes it high-quality" are misguided and should not implement such policies in their own products. It's not what you're doing, and if it were, it wouldn't work.
wibble10 8y ago
It’s part of OpenBSD who can’t use git for licensing reasons and the switch from cvs->svn isn’t really worth it. There is a git mirror on github and you can work on that and submit diffs to the mailing list if you’re worried about having to read the cvs manpage ;)
- avar 8y ago
  Let's make something clear: They can, and they use other GPL software in the base system. They just choose not to, for (as I understand it) a combination of reasons. Being averse to relying on new GPL code, being "happy enough" with CVS (also working on OpenCVS), and CVS being a little more than just source control for them due to the likes of CVSync[1]. I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it. 1. https://www.openbsd.org/cvsync.html https://www.openbsd.org/cvsync.html
  - Crinus 8y ago
    Aren't "patches in Git" just "patches"? Git can give you a patchfile that can be applied with "patch" regardless of VCS.
    - sneak 8y ago
      from GP: "I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it." I think he means he is a contributor to the source of `git` itself, and thus is justified in saying "we" in terms of not prohibiting OpenBSD's contributors from using the software he helps develop (git).
      - avar 8y ago
        Correct. Thanks!
  - simias 8y ago
djmdjm 8y ago
For workflows, we have good tooling based around https://github.com/yasuoka/cvs2gitdump https://github.com/yasuoka/cvs2gitdump to convert OpenBSD CVS commits to git commits in a "pristine upstream" repository (https://github.com/djmdjm/openbsd-openssh-src https://github.com/djmdjm/openbsd-openssh-src) and merge them to the portable OpenSSH repository. Merging changes from OpenBSD to portable is usually completely painless and only a hassle when merging something really large (in LoC touched) like a refactoring. It would certainly be easier for external contributors (and us) if OpenBSD used git natively but as OpenBSD was AFAIK the first open source project to expose a CVS tree of their work to the world there's a lot of legacy to overcome.
microcolonel 8y ago
I know the process of using CVS has prevented me from making drive-by contributions to OpenBSD. If you just have a specific change in mind, and you saw how to do it on the anonCVS browser while you were out and about, the pain of setting up the CVS and working with it is usually enough to just give up and read a book when you get home instead.

geocar 8y ago

> and if that tool makes it harder for external contributors to contribute? I hope so! OpenSSH is a critical piece of infrastructure in most unix and linux environments, so making sure external contributors do some extra diligence seems like a good thing!

brylie 8y ago
It may be important not to confuse "diligence" for "encumbrance".
sneak 8y ago
The willingness to jump through outmoded and unnecessary hoops does not correlate to the quality of one's cryptographic code. In fact, many who are deliberately diligent will shy away from teams who care more about tradition than quality, in my experience.
geofft 8y ago
Learning CVS is not "diligence." If anything, it takes up mental space you could be using on things like remembering to bounds-check your array accesses. Asking contributors to learn CVS as a quality gate is like having a tech interview process that requires beating the hiring manager at chess. Sure, you're looking for smart people, and sure, people good at chess are usually smart, but the correlation is so low you'll lose out on good candidates and get candidates who are better at chess than coding.
- djmdjm 8y ago
  We don't ask anyone to learn CVS. People send the maintainers (myself and other) their changes (git format-patch is fine) and we integrate them.
  - geofft 8y ago
    Yeah, to be clear I think you the OpenSSH maintainers are quite responsive to people who aren't using CVS (in particular, thank you for digging into https://bugzilla.mindrot.org/show_bug.cgi?id=2863 https://bugzilla.mindrot.org/show_bug.cgi?id=2863 which didn't even have a patch!). I just want to be clear that people who look at what you're doing and say "OpenSSH is using an obscure process, that's what makes it high-quality" are misguided and should not implement such policies in their own products. It's not what you're doing, and if it were, it wouldn't work.

wibble10 8y ago

It’s part of OpenBSD who can’t use git for licensing reasons and the switch from cvs->svn isn’t really worth it. There is a git mirror on github and you can work on that and submit diffs to the mailing list if you’re worried about having to read the cvs manpage ;)

avar 8y ago
Let's make something clear: They can, and they use other GPL software in the base system. They just choose not to, for (as I understand it) a combination of reasons. Being averse to relying on new GPL code, being "happy enough" with CVS (also working on OpenCVS), and CVS being a little more than just source control for them due to the likes of CVSync[1]. I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it. 1. https://www.openbsd.org/cvsync.html https://www.openbsd.org/cvsync.html
- Crinus 8y ago
  Aren't "patches in Git" just "patches"? Git can give you a patchfile that can be applied with "patch" regardless of VCS.
  - sneak 8y ago
    from GP: "I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it." I think he means he is a contributor to the source of `git` itself, and thus is justified in saying "we" in terms of not prohibiting OpenBSD's contributors from using the software he helps develop (git).
    - avar 8y ago
      Correct. Thanks!
- simias 8y ago

djmdjm 8y ago

For workflows, we have good tooling based around https://github.com/yasuoka/cvs2gitdump https://github.com/yasuoka/cvs2gitdump to convert OpenBSD CVS commits to git commits in a "pristine upstream" repository (https://github.com/djmdjm/openbsd-openssh-src https://github.com/djmdjm/openbsd-openssh-src) and merge them to the portable OpenSSH repository. Merging changes from OpenBSD to portable is usually completely painless and only a hassle when merging something really large (in LoC touched) like a refactoring. It would certainly be easier for external contributors (and us) if OpenBSD used git natively but as OpenBSD was AFAIK the first open source project to expose a CVS tree of their work to the world there's a lot of legacy to overcome.

microcolonel 8y ago

I know the process of using CVS has prevented me from making drive-by contributions to OpenBSD. If you just have a specific change in mind, and you saw how to do it on the anonCVS browser while you were out and about, the pain of setting up the CVS and working with it is usually enough to just give up and read a book when you get home instead.