Hacker News Reader

Comment by cnorthwood | Hacker News Reader

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?

View on HN

For workflows, we have good tooling based around 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) 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.

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 ;)

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

Aren't "patches in Git" just "patches"? Git can give you a patchfile that can be applied with "patch" regardless of VCS.

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).

Correct. Thanks!

>also working on OpenCVS

Are they really though? I can't remember for how long "OpenCVS is to be released soon"[1] but the page itself begins the copyright in 2004.

While I respect other technical decisions taken by the OpenBSD team this one strikes me as pure hubris. Sticking to SVN I could sort-of understand but CVS is just ridiculously frustrating to work with.

[1] https://www.openbsd.org/opencvs/index.html

Looking at archive.org, the page has had "to be released soon" since at least 2005 [1]. So I think your skepticism is in order.

[1] https://web.archive.org/web/20050130011942/https://www.openb...

> (also working on OpenCVS)

Not actively. It has been in hybernation for a long time.

Not counting the recently-ish fixes I committed not much is happening with it.

Dragonfly has git in base so that, in and of itself, is not the reason why.

DragonFly uses git but it's only a package like chromium or xfce.

No, it is in the base of the system. I just did an install of the base system and it is there.

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.

> 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!

It may be important not to confuse "diligence" for "encumbrance".

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.

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.

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.

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 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.

Reply on news.ycombinator.com