1. 49
  1.  

  2. 14

    I think the title of this post is a bit misleading. “OpenBSD Git mirror now on GitHub” might be better, because “OpenBSD is on GitHub” makes it sound like the project has moved to GitHub, or is actually using GitHub in some way (pull requests, etc.). We’re just making a read-only Git conversion of our CVS tree available in a public place (because it was easier than assembling our own read-only Git mirrors).

    1. 8

      I asked about it on twitter and was told it’s still not considered a stable conversion (the commit hashes may change in the future if necessary). I think this is a great resource to have, but be aware of the limitations.

      https://twitter.com/AFresh1/status/787856634089381888

      1. 4

        Is this just a mirror or are OpenBSD taking contributions via pull request?

        1. [Comment removed by author]

          1. 5

            Are there specific reasons for this? ruby/ruby allows posting pull requests as long as there’s a tracking issue on the bug tracker for larger things and takes the time and effort to point people to it if necessary. It’s not much, that can be solved by having a block of standard text or even just putting it in the pull request template github provides.

            1. 11

              OpenBSD just doesn’t do github pull requests. That’s not how we work. The project mostly only relies on its own infrastructure; github is not part of that.

              Another reason why pull request won’t be looked at is that you need a browser to use them. When doing reboots all the time during kernel development starting a browser, or even having a browser installed during a libc ABI bump is just a hassle.

              1. 4

                You can easily extract the patch by appending .patch: https://patch-diff.githubusercontent.com/raw/skade/lazers/pull/15.patch . You can respond to PR notifications through email, even send them to your mailing list if you are so inclined.

                Assuming you have some way to do HTTP (which I assume if you have some way to read email), you can extract the patch there.

                My point was more: why put a sign up that says “if you land here, we will ignore you, because you are not us”, when you could put up a sing “hey, hello, you are welcome, but for many reasons this is not the way we work, but we will happily teach you (and maybe accept small fixes with a grumble)”.

                Ruby has also not switched over to Github for many good reasons (one of them being a lot of specialised tooling built around their infrastructure), but they appreciate that this is an angle of approach to the project and will help people coming from there.

                Don’t get me wrong, I do understand and support the reasons for doing your own flow. But why actively working against fresh people that know another flow?

                1. 4

                  It’s a little ironic that the solution to “github is unfamiliar” is “hack the URL to add a secret extension”.

                  1. 3

                    The URL is not obscure nor secret, it’s in the email notification you get for a pull request, right next to the link to the diff.

                    1. 1

                      Ok, that’s fair, but it’s not obvious how one would discover that without already switching to GitHub.

                2. 2

                  It’s not quite true that you need the web to use them (though commenting on them probably does - which is a big part of reviewing):

                  https://gist.github.com/piscisaureus/3342247

                  But kudos on using your own infrastructure (I’m on a bit of an anti-SaaS kick right now)

                  1. 2

                    There is also the GitHub CLI for those that prefer doing most work outside a browser.

                    I’m on a bit of an anti-SaaS kick right now

                    Ditto. I do wish Gitlab was a bit easier to manage - I’d love to install it but the number of dependencies along with the frequent security updates make me a bit leery. Gogs looks good but I need to investigate further.

                3. 5

                  Pull requests don’t encourage the same kind of code review as email-based workflows:

                  https://lobste.rs/s/rkux7i/why_kernel_development_still_uses_email/comments/vodxjs#c_vodxjs

                  1. 2

                    I’m not saying you should move discussions over, but you can still extract the patch and move the people over to your infrastructure. Would you prefer to leave potential commiters there?

                    1. 5

                      The quality of the patch itself is also affected by the medium. People just don’t write “patches” when they use PRs. They write a big pile of commits where whitespace changes are mixed with bugfixes are mixed with new features, all at once, with fuzzy boundaries across commits. There’s also the whole rewriting of the commit/patch stack that seldom happens with a PR, because that involves “scary” push-forces that partially lose the history of the code review, whereas with email it’s just a resend.

                      I don’t know about OpenBSD, but for the projects in which I have seen, yes, I much prefer the quality of the patches sent to email than what I’ve seen in PR. I am grouchy and would not miss leaving behind PR-based commits, because their quality tends to be lower.

                      1. 3

                        I don’t know about OpenBSD, but for the projects in which I have seen, yes, I much prefer the quality of the patches sent to email than what I’ve seen in PR. I am grouchy and would not miss leaving behind PR-based commits, because their quality tends to be lower.

                        Would you feel comfortable leaving behind the potential committer that could learn your way of writing patches?

                        1. 3

                          Some might argue that any potential committer should be keen enough to learn the way a project works. But I can see the value in your approach (and it’s one I’d favour personally - help people to swim rather than throwing them in the deep end, where only the strong survive). Wow, what a selection of mixed metaphors there!

                          1. 2

                            Some might argue that any potential committer should be keen enough to learn the way a project works.

                            Sure, I wouldn’t work with people that absolutely refuse the projects flow. But any approach should me met with the benefit of doubt and is an opportunity to start a conversation, ask people to clean up their patch etc.

                            E.g. when I first submitted to freedesktop, I had to set up git send-mail. It’s horrible. It was hard to find out I even had to do this and then which the exact mailing list to send it to was, as the one I though was correct was slighly abandoned and full of spam. Took me around 5 hours for a tiny patch.

                            The review experience with the freedesktop people was stellar, then. But the patch nearly got lost on the approach, and I have been doing things like that for nearly a decade.

                            On the other hand, people complain about lack of committers.

                            1. 10

                              5h for a first patch submission is really not that much. Excepting to spend as little time as possible on submitting a patch makes it sound like the submitted contribution is a “fire and forget” one. Those can of course be nice, but no project can survive on them. Which is why contributors who avoid learning the tooling used by a project are really not that interesting.

                              In OpenBSD’s case, consider that all developers are already volunteering a significant chunk of their time following the mailing lists and reviewing patches by fellow developers and new contributors. When your goal is security, every change can be dangerous. So code review applies to everyone, and the project relies on everyone to be involved in the canonical code review process to keep the code base stable and secure. .Email is where the real action is in this project. If a non-trivial change made it into the central repository but was not shown on a mailing list, or at least to other developers involved in the area, this would be regarded as a major problem..

                              With a well established (since 1995) process like that, moving the attention span of even just a few developers to a different platform than email can be a huge distraction. Yes, it serves outsiders who don’t feel like learning the tooling. But suddenly everyone has to watch two spaces for upcoming changes to review, because it’s not all in the one usual place, and who knows what kind of breaking changes the other subgroup over on github is up to.

                              Your best bet for contributing by pull requests it to ask an existing developer to accept pull requests from you and then channel them to the mailing list on your behalf. But why would any existing developer want to do that?

                              1. 6

                                I am inclined to agree when submitting a patch requires jumping through extra hoops. In this case, we’re asking people to do less work, not more. All one need do is send the output of git diff to the list. I’m pretty sure that’s actually less work than creating a pull request.

                                1. 2

                                  Email? What is that? Some obsolete version of slack?

                                  I agree with everything that has been said here by OpenBSD developers. The proportion of quality patches received over email is light years ahead of the proportion of good GitHub pull requests. And this doesn’t even address the fact that GitHub pull requests force you to use a particular kind of workflow, while email allows actual developers (the people who do 99% of the work) to use what workflow they prefer. Sure, they don’t allow the casual contributor to chose arbitrary workflows, but that is a feature (not a bug) of the release engineering process.

                                  The process is stable and works very well.

                4. 2

                  I believe it’s just a mirror and I doubt contributions are being taken via pull request (although @jcs can confirm).

                  BTW, the mirror has been there for quite a while if I’m not mistaken…

                  1. 4

                    It’s hitting news because of the official link on the openbsd.org website. See the commit.

                    1. 5

                      Or maybe this one ;)

                      1. 5

                        I prefer this one ;)

                        1. 1

                          Yes! That’s the good one! :D

                5. 3

                  Relevant openbsd-misc thread here

                  1. 12

                    Some of the ppl on the mailing list aren’t very good at being clear and compelling in conversation. That thread is… wow.

                    1. 9

                      For example:

                      Is this https://github.com/openbsd the official OpenBSD github site?

                      Nowhere on the OpenBSD website mentions github as anything official. So you just assumed that the seven letters, “openbsd”, in that order, makes it officially part of the project?

                      No… that’s why they went and asked the mailing list.

                      1. 10

                        Yep. That’s not a mailing list I’d want to read, let alone write to.

                        1. 7

                          Sadly, there are too many threads on -misc that go like that. I think it presents such a negative view of the project to those who may be encountering OpenBSD for the first time.

                          1. 9

                            It definitely seems… toxic.

                            1. 9

                              A mailing list rampant with ragey old BSD hackers? Toxic? SHOCKING!

                              1. 13

                                I’ve been around mailing lists for a long time (and BSD communities for almost as long) and I’ve never encountered a list quite like openbsd-misc (and I don’t mean that as a compliment). Certainly, none of the NetBSD and FreeBSD lists are like it… (and nor is openbsd-tech).

                                1. 5

                                  That doesn’t speak well of the community. Kind of a shame. No reason not to keep things civil. We’re all adults here (or should be).

                              2. -2

                                Define toxic… if something survives, it has merits, even if you can’t appreciate it.

                                1. 8

                                  Nobody’s questioning the merits of OpenBSD

                                  1. 0

                                    I’m talking about the mailing list, just labeling their mailing list toxic with (I assume) very little knowledge of the individuals, or the culture, or context seems to go against being ‘non toxic’ too.

                              3. 4

                                As long as the grumpy neckbeards/neckbeardettes are writing code that works, more power to them.

                                1. 5

                                  The thing is that -misc is more like a peanut gallery for holier-than-thou neckbeards who aren’t even contributing to the project.

                            2. 8

                              Not really. That thread is old and mostly irrelevant.

                              1. 7

                                August 2016 is not that long ago even in JavaScript years :-)

                            3. 1

                              Relevant podcast episode about this: garbage[39]: Provenance