1. 30
  1.  

  2. 14

    Making and submitting diffs to OpenBSD is lovely. There’s so little process. It’s pretty much fire and forget, as long as the diff is good enough to be committed straight away. Maybe you need to come around and tweak it a little, or bump it if the tree was locked or all the devs were busy when you first submitted.

    Last few days, I’ve been tinkering with Firefox, just a little. Oh boy the process feels involved by comparison. Of course you need a bugzilla account; every patch needs to be associated with a bug. Of course you need to know their bug & patch submission rules. And you need to know who’s going to review your diff, because you need to flag that person to get the diff reviewed. You need to figure out the clunky UI. And ideally all changes are supposed to be tested on the try server, which you probably can’t access as a newcomer. Only after you’re done with all of that do you get to flag the bug for check-in. Then you wait for somebody to come and commit. The whole process looks a little daunting when you start reading the docs that cover it.

    It’s by no means bad. I guess that’s just what happens, and more or less needs to happen, when projects grow big. But every step along the way I’m reminded of how nice it is to just send a message at tech@.

    There was another project I was going to send patches to. First thing first, they wanted me to sign a copyright assignment. I never sent those patches. That was a GNU project…

    1. 10

      Don’t be discouraged by the process. Firefox is a product that is used by a couple hundred million people. There is a big focus on quality and performance and correctness.

      Do it a couple of times. It gets easier.

      1. 5

        Don’t be discouraged by the process.

        Don’t worry. I won’t. It’s not hard – there’s just some friction. The barrier to entry is much higher than with e.g. OpenBSD. And the UX is clumsier, at least for small changes.

        Firefox is a product that is used by a couple hundred million people. There is a big focus on quality and performance and correctness.

        Mozilla’s tests might be more comprehensive than OpenBSD’s array of regress tests, but apart from that, I don’t believe the process imposes a meaningful difference in terms of quality or correctness. It’s just a different way to communicate. Ultimately both projects have people who are responsible with reviewing and committing changes. Mozilla’s process sure does a good job of leaving a trail to follow when some commit needs to be reviewed in depth years after it’s landed.

        1. 0

          Firefox is a product that is used by a couple hundred million people. There is a big focus on quality and performance and correctness.

          Then why is it so low quality (e.g. doesn’t look like a native application on macOS), low performance (so. slow.) and incorrect (e.g. doesn’t do color management on maxOS)?

          1. 8

            None of your complaints are related to quality or correctness.

            Personally I agree with performance, the UI often doesn’t feel that snappy and having a bunch of extensions running javascript hooks on your xml/xul browser doesn’t help.

            But I give them a break since they are basically the best shot we have at maintaining an open web.

            1. 4

              Have you tried current nightly builds of Firefox? Performance is amazing with all the latest features enabled. (multi process, async pan and zoom, parallel CSS engine from Servo)

              1. 2

                None of your complaints are related to quality

                We must disagree here. Lack of native look and feel is definitely lack of quality in my book.

                or correctness

                Here I must insist. Firefox produces metrologically incorrect colors. Producing correct colors is definitely a question of correctness.

              2. 1

                What does it mean for a browser to do color management.

                I’m with you in the other stuff, hoping things start coming together in 57.

                1. 3

                  Actually systems provide device colorspace independent graphics APIs, so in an ideal and simple world browsers would not have to do almost anything and everything would work correctly. The only thing browsers would have to do is inform the graphics API of the input color space (from embedded ICC, otherwise defaulting to sRGB). MacOS works like this, I assume other systems work the same.

                  But browsers don’t do that, why would they keep it simple. In the name of performance, or whatever other reason, they prefer to render to bitmaps that are put on the screen uninterpreted further by the graphics pipeline. The only way to do this correctly is if you actually keep track of the display color space and do all graphics primitives accordingly.

                  Browsers are very confused about this, to varying degrees, and the degree of confusion depends on the target operating system. The only browser that does it 100% metrologically correct is Safari.

                  In reality all of this is a very simple problem even if you decide to implement it yourself rather than rely on the operating system. CSS colors and untagged images are defined to be described in sRGB by various web standards, tagged images contain obviously their own ICC profile. The only thing you have to do is use this information to operate in some abstract color space and render to the target display color space. Coincidentally these are all very simple linear operations that can be implemented in a GPU shader with virtually no performance impact.

                  http://cameratico.com/tools/web-browser-color-management-test/

                  1. 2

                    What does it mean for a browser to do color management.

                    There’s more than one mapping of 0-255 RGB values to real world colors. Default JPG would be sRGB, but the monitor may not be, and you need to remap the colors or things will look weird.

              3. 2

                Interestingly, FreeBSD uses a Bugzilla, but there’s no complicated process, it’s also fire and forget for simple patches.

                First thing first, they wanted me to sign a copyright assignment.

                oh yeah. Google is also guilty of this. They want you to sign a CLA… yeah simply by filling out a web form… but that form ASKS YOU FOR YOUR ACTUAL PHYSICAL HOME ADDRESS. What the hell?!

              4. 4

                Although the final modification is not my code, it is still a great pleasure that I contribute my own effort to help make OpenBSD better!

                Why was it not your code?

                I don’t know the full story since Marc.info is down but if this contributor was not mentored to finish the patch then that is a bad experience in my opinion.

                There is nothing worse than making an effort to submit a patch and then have someone “just do it the right way” for whatever reason.

                1. 8

                  The committed diff has trivial style changes (using ? : instead of if-else). The contributer was mentioned in the log message, which also stated the committed change was derived from the patch which was submitted. It probably didn’t help that the patch was sent with whitespace mangled so it couldn’t be applied automatically. Given these circumstances I would say it was handled just fine.

                  If the change had been more involved I would tend to agree that letting the submitter work out remaining problems is the right thing to do. But I don’t think mentoring should be mandatory and expected in every case.

                  You’re saying there was nothing worse but I think there is: I submitted this patch which got committed without any attribution. But I sent it privately to the developer so there is no public record that it happened this way.

                  1. 2

                    You’re saying there was nothing worse but I think there is: I submitted this patch which got committed without any attribution. But I sent it privately to the developer so there is no public record that it happened this way.

                    So there was this one (admittedly very minor) patch I sent to OpenBSD quite a while ago. It got committed much later, without attribution. And I am just glad it’s in :-) I sent it to improve the state of things, and not to get my name in the cvs log. These days I’m actually thinking of doing more and more anonymously, or at least under a pseudonym that isn’t easily connected to me.

                    To each their own, I guess. I could think of much worse. Like being told to go away, by the project leader, while trying to help another user on the lists. Thankfully I haven’t received such treatment. Then again, I don’t really try to help others on public lists. :-)

                  2. 4

                    There is nothing worse than making an effort to submit a patch and then have someone “just do it the right way” for whatever reason.

                    Maybe it depends on the goal? I guess if the goal is to train an employee to the house rules, sure, mentor them till the end. If it’s someone who’s coming back to contribute, or trying to contribute a large amount of code, sure, invest the time.

                    But for some random person filing what might be a one-off patch, it might just be counterproductive to start by nitpicking about style and detail. And mangled whitespace. It might just scare them off? I don’t suppose most people would feel offended if someone tweaks their diff a little, commits it, and then thanks the sender. I wouldn’t be offended.

                    If they come back and start sending more diffs, maybe there’s time to nitpick?

                    marc.info works for me right now. Here’s the committed version: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dmesg/dmesg.c.diff?r1=1.27&r2=1.28

                    1. 4

                      There was no thank you. No “hey that is a great fix, ready for something bigger?”. Just silence and a fixed up commit.

                      Most contributions start small. Most contributors start with a small patch to get their feet wet.

                      Now I don’t know the OpenBSD project, but like all open source projects it probably heavily depends on contributors. So why not make people feel inclusive and foster their work. Help them grow into productive contributors.

                      That is not happening here.

                      1. 5

                        | Based on a diff from xiao_nan (at) dsi (dot) a-star (dot) edu (dot) sg - thanks.

                        https://marc.info/?l=openbsd-cvs&m=150373760724279&w=2

                        1. 3

                          I see your point.

                          I’ll note that I’ve (nearly?) always been thanked in private by the committer when I’ve sent a patch to OpenBSD. I’ve always felt inclusive in my communications with the OpenBSD committers. I assumed the OP was also thanked, and that they also felt inclusive and good about it:

                          Although the final modification is not my code, it is still a great pleasure that I contribute my own effort to help make OpenBSD better!

                          I’ll also note that I’ve received more silence and fewer thank yous from Mozilla. My first (trivial) patch went in silence. Maybe I got some automated message congratulating me for the r+. Not that I mind. (Sorry, I know this topic isn’t about Mozilla, but since I brought it up already.. anyway I don’t mean to bash)

                          1. 2

                            No worries. Mozilla is far from perfect when it comes to contributor engagement. I’m sorry that was your experience. Shoot me a bug number if you need help to get things moving.