I mean, Gitlab is a web platform. It's pretty easy to test how it's going to work on different platforms without needing full machines. Heck, you can even just get Microsoft Edge binaries on macOS and Linux if you want to test Edge. But failing that, VMs are pretty sufficient.

Tell that to the FE devs who add `overflow: scroll` everywhere and don't spot the problem...

God yes, I hate how all FEs have tunnel vision on MacOS nowadays. Our sign-up flow had godawful scrollbars both horizontally and vertically for the longest time but they didn't notice because they're all on retina display Macbooks instead of what the bulk of our users will be using.

Macos do have a option to always show scrollbar. And I think this is a pre-requirement to enable that if you ever care about what your user may actually see as a FE.

Besides that, there isn't actually obvious different between firefox/chrome/edge on macos/windows.

The most problematic one is actually safari(which is on mac only). If you dev on chrome and use on firefox or vise versus. You usually get a "mostly work with minor visual different". But safari… will give you a fail and are't even usable. It is outright the modern age ie.

In the past, I was able to reproduce a supposedly Safari-only issue using Epiphany on Linux. This browser uses a closely-related engine.

A solution is to have somebody in each FE team with a "that's what the masses use" device. Screen-wise, CPU-wise, RAM-wise, network b/w wise. And let them use it as a primary dev device.

Doesn't sound sexy, no. Compensate them royaly. And make clear that they are superstars just by having this work environment. Then keep listening to what annoys them with whatever you are building, and let them fix it.

I agree with this nitpick. Unfortunately, I think we are losing that battle, because more platforms are adopting the hidden scrollbar (anti-)pattern.

That, however, is bound to happen even if you have Windows workstations. It happened at a job where I was, in fact, running Windows, because the designer ran macOS and was oblivious to this issue. (Of course, I would fix it when spotted. But it still managed to make it out to prod at times.)

What's especially nuts about this to me is that macOS supports static scrollbars! System Preferences → General → Show Scroll Bars → Always.

Or, leave the default settings in place, but plug in a mouse with a physical scroll wheel.

So it's not even that they're only using one platform, but they're only testing the platform with default settings with the default hardware. And we're not even talking about an obscure setting buried three levels deep, it's right there in the general pane!

Or on the command line:

  sudo defaults write -g AppleShowScrollBars -string Always

I include this as part of my setup script for any new Mac.

This can be fixed by toggling a single MacOS setting to make the scrollbars always visible so that FE devs can feel the pain they are causing to their non-Mac using customers. Can be included into onboarding process. No need for a real windows machine just on that account.

This is one of the first things I always turn on with a new Mac. And I always encourage everyone on my teams to turn this on because otherwise it goes completely unnoticed until we get that huge surge of issues and product being angry because Windows users complain about it.

But I also place the blame on design teams. Most design teams I've worked with also doesn't account for this in anything they create. They usually only design for: 1: the latest macbook pro; and 2: the latest iPhone.

I think YouTube comments have a bug like this right now. On Windows I frequently see a giant horizontal scrollbar across some comments that doesn't even move, or moves very little.

VM's are sufficient only if you want "idk, it runs kinda glitchy on the VM" to be the end of the conversation when Windows-specific bugs come up in dev. And "idk, works fine on the VM" when Windows-specific tickets come up in prod.

The binary is still platform specific. Chrome, for example, does not render identical select element menus across platforms and certain select style rules are interpreted differently across said platforms.

I'll give you a point on VMs but it's cumbersome. There's a big difference between rolling to another machine or asking someone in the department who uses that machine every day and waiting for a VM to finish booting or using a service like Browserstack (and both cost $$ anyway).

Not if you're doing any kind of accessibility testing, and considering they want to sell to the US government, they will have to at some point.

Screen readers are not consistent across platforms, and things that work on Windows sometimes don't work on other platforms, and vice versa.

I have done this using virtual machines.

Gitlab ships various ci runner executables for all platforms. I use their Windows ci runner and it works well, but I wonder how they test it without running windows.

This policy about which OS your laptop runs does not seem to preclude the use of Windows VMs (and presumably CI runners, though I bet we could see if that was the case ourselves) if it were needed. The open source nature of Gitlab also makes it easy for a developer to test things on an unprivileged personal device, I'd imagine.

If that was not enough, I believe the CI runner is written in the Go programming language, which has a surprisingly decent abstraction of OS functionality in it's standard library. Imperfect as it may be, I suspect that helps reduce the amount of effort needed to ensure individual platforms work properly.

This is exactly how I used to operate. I'd develop on Linux then ensure it works on Windows in a VM.

This is a policy for personal workstations. Presumably, there is a different policy for QA/CI environments.

> Gitlab ships various ci runner executables for all platforms. I use their Windows ci runner and it works well, but I wonder how they test it without running windows.

Maybe with a Windows VM.

If that’s the case then Windows isn’t actually prohibited at Gitlab.

It is prohibited at Gitlab according to this policy. On developer laptops. It is not necessarily prohibited in all contexts. The one-line title could've been slightly clearer, but I think it's a totally fair statement.

The prohibition on developer laptops is not just a trivial or nitpicky detail; while the security of a VM obviously still matters, as you can't simply assume that malicious software in the VM can't escape, I would assume that the policy effectively means it would also be prohibited to setup a Linux dom0 and just run Windows under that and use it as your developer workspace. The benefit of only using Windows for testing is that you presumably won't be reading emails, talking on team chat, taking video calls, opening documents, etc. inside of Windows, only doing the thing you actually need (testing.) From a security standpoint, this can be helpful. I think that Windows vs Linux security is a rabbit hole not worth debating; both are very flawed and have many challenges, nothing is a panacea. However, I would say that every OS you don't need to harden is a huge operational advantage no matter how you slice it. You effectively cut off an entire slice of the malware market, and easily the largest slice in case of Windows.

If you would have kept reading, you would have noticed that employees can apply for an exception to the policy.

So if, for example, you are a UX dev and need to test your CSS on Edge, they have a process that allows you to do that.

And it's not "just a bit of money", Microsoft's enterprise product licensing is truly onerous. It's almost a career unto itself just to make sense of it, and it requires a non-trivial amount of infrastructure to support.

I agree. If nothing else they won’t be able to replicate Windows typography, which is different from Linux and OS X. Base fonts are different; kerning and anti-aliasing are different. Web design is still 90% typography, and cutting the largest install base out of your test matrix seems silly to me.

I have a company laptop that runs Windows, but everything I work on runs on an ARM-based device.

Work computer != target machine

For about 20 years, I've not developed anything at work that runs on the work computer that is used for doing the development, documention, e-mailing and whatnot.

Do you mean px issues, which web standards ought to solve, or just how typography looks from a design point of view?

Gitlab is essentially a website, and Microsoft Edge is just Chrome. I think there isn't any reason to test on windows anymore.

Developing "essentially a website" is my full time job - if you genuinely don't think there are differences between platforms, you aren't paying attention.

The browser is wired into the OS in real ways, and they matter. Everything from "How does the os manage passwords" or "how are system notifications presented" or "How much screen real estate do I have have on a given window size (scrollbars...)" to subtle differences in how the network stack behaves, or how windows are rendered.

Hell, I can list about 20 differences just off the top of my head - and a damn good part of that is because I've been forced to pay attention to each of those platforms. Which clearly you have not...

I read your comment as "I only use a mac, and I don't understand".

Have you been using Gitlab lately? I don't think they have any interest in nuances, as they still have problems with basic stuff.

Overall i'm pretty sure that "list about 20 differences" is relevant in some cases/procucts/websites, but not for gitlab - they just proved that by disallowing working on Windows (which wouldn't disallow testing on a VM).

I've been making software for almost 10 years and password manager/notifications/responsiveness is not dependent on the platform that's why we have web standards.

You clearly haven't been paying attention, then. It's easy to spend decades making crappy software.

> It's easy to spend decades making crappy software.

But here's the important question: are the problems that are caused by ignoring the aforementioned differences enough to prevent people from being able to use your software? Or, conversely, are they enough to weigh more heavily than the functionality that you provide for your users?

Because somehow even Electron based software is pretty popular in the desktop, oftentimes looking and feeling rather different from most of the native software. But apart from nitpicks and rightfully complaining about those annoying inconsistencies, does it really matter enough to spend resources towards fixing them?

I can't think of that many inconsistencies that caused web applications to be unusable across different platforms altogether, apart from IE not supporting certain JavaScript functionality back in the day and non-transpiled (to say, ES5) codebases breaking altogether. But look and feel related things have hardly been as important.

You are absolutely right.

There can be weird differences that show up on different operating systems, even with the same browser.

For example, we ran into a difference between Chrome on Linux vs Chrome on macOS where it turns out that on macOS, if you right-click on a link (to open a context menu) it selects the text of the link, while on Linux it does no such thing. Initially we'd tested on only one platform because we assumed they'd behave the same, and this difference resulted in buggy behavior on the untested platform.

Famous last words.

There are definitely differences between mac and windows (possibly linux) when it comes to font availability/rendering(maybe?)

I've seen more than once a mac design use some font in a light weight that comes across almost invisible on Windows. I'm the only windows guy at our shop and "everyone has access to windows VMs to test" (lol)

Outside of that, now that Edge is on Chromium most of our edge cases seem to be Safari these days (everyone uses chrome/firefox except a couple management using Safari).

Which all in all I guess is a testament to our lack of full browser testing :)

¯\_(ツ)_/¯

Give a try to add a drag listener mix with a double click listener on the child element, you end up with a bug only with windows laptop trackpad.

Then I'll give you one: autocrlf.

In fact, if you paste text into GitLab's "Web IDE" in a windows browser, the results are (or at least used to be? We stopped using it because of that) horrible to the max. Of course with the added nuance that copy-pasting a word vs. a paragraph vs. an entire file produced vastly different results, too. That one was fun to figure out.

Windows is a specific set of skills that takes a lot of people to do properly at any scale. The dedicated resources required are essentially a drain on the whole of IT. My company also bans Windows for the same reasons.

For many years, and in so many companies, the policy has been the opposite.

All company laptops must have windows, anything else needs to be vetted by the IT admin.

Now that the Edge browser works fine on Linux, there's really no need for all these licenses, and someone needs to start to break the unhealthy dependency every company has on Active Directory.

Yep. I find it kind of surprising that this is news. There are so many companies where nothing but Windows is allowed, but not allowing Windows in one corporation with a major Microsoft-owned competitor is the issue?

Testing for Windows on a non-Windows machine is far easier than testing for macOS on a non-macOS machine. Of course, having people use both is better. IIRC, Steve Klabnik uses Windows to ensure that Rust supports the platform well.

It doesn't sound like Gitlab doesn't allow windows at all.

This sounds to refer explicitly to using interim personal laptops until departmental hardware is issued formally (which, as I understood it, may then run windows).

Did I misread?

You did. See https://about.gitlab.com/handbook/security/approved_os.html

you're gonna have a bad day if you're depending on random employees for testing a site used by millions.

instead, invest in:

- real automated testing (to the extent technically and economically feasible). One hack is to get customers and partners to fund it, then leverage outsourcing.

- feedback from users - make it easy, streamline responses, setup escalation. Understand that you can't nail down everything and quickly triage issues. Scale the team so at least you can do the triage.

Do you also expect that mobile devs do all their primary computing from their phone?

I certainly expect them to be driving the phone they are developing for - in the case where a single team is doing both iOS and Android - yes, I expect them to be using both consistently (and I argue for issuing both at companies where I've led mobile teams).

I've been down the whole "we'll just test it in a vm" path, and it works... if by works you mean you get a happy path test every once in a while, and devs make sure the automated tests pass.

It doesn't instill the same level of care and attention that daily use gives. Dog-fooding is not a joke. It's genuinely hard to make a decent UI for a platform if you're not using that UI often, and in real situations.

I've literally gone as far as making devs switch device personas over time on my mobile teams. They get an assigned device from our test pool for the sprint from a list like

- High end stock android device with large screen

- High end stock android device with small screen

- High end Samsung ROM device with large screen

- High end Samsung ROM device with small screen

- Mid tier stock android device with large screen

- Mid tier stock android device with small screen

- Mid tier Samsung ROM device with large screen

etc... down to the devices no dev wants at all, like

- Amazon Kindle Fire default

- Amazon Kindle Fire kids

and they do all their dev/testing/use on it.

It works fucking wonders in suddenly making them care about things that were previously just "meh" problems. Two weeks stewing in their own problems on a device they were ignoring is one hell of an incentive.

It's common for companies to encourage their dev workforce to use a broad variety of company-provided mobile devices so that, while dog-fooding, they get better coverage.

Realistically... Microsoft owns GitHub, and the weird Azure devops-ish solution for git. If an enterprise is on Microsoft, they're going to use one of those two solutions instead of GitLab.

Making IT's life _vastly harder_ to allow employees to maybe use Windows and see a solution the testing team didn't see is not a good trade-off.

That's not even going into how, exactly, Windows is going to make anyone's life better than using a Mac. Realistically, they're at least at parity.

The trade-off here is "make every IT support and supply line more filled with friction" to gain "people can use Windows if they'd really prefer, instead of Mac or Linux". That's a terrible trade-off, and GitLab is making good decisions.

Take into account that they prohibit Windows Home specifically.

In my company I am dealing with buying laptops for new hires - there is no way I am buying laptop with Windows Home edition.

That is problem with explaining people that they should buy laptop with Windows Professional. Whatever the cost is - company is paying. New hires are shy to expense company THAT is the problem.

So I think problem is that people try to buy cheapest laptop they can to "be cheap".

If my company would be on scale of GitLab I probably would not be able to control that but I am specifically buying laptops via my manager - and there is no way we would buy Windows Home laptop.

This document seems to be about the machines that employees at Gitlab are given, not about target machines for testing and deploying software.

They probably have some Windows machines at Gitlab for verifying the experience of Gitlab users/customers who use Windows.

I imagine a developer doing that would have a dedicated Windows machine, or possibly a guest VM, for that activity.

You're never going to get the same coverage with some test VMs compared to people actually using the product on their primary machine every day.

Does anyone know if this policy is causing GitLab's product quality to suffer? I see your argument, but products like BrowserStack and VMs can be employed to mitigate some of the negative effects. It seems premature to call the policy bad without examples of harm it has caused.

Not sure how that compares to all the companies that require Windows.

I guess is is for developers and business but in some other areas Windows would be hard to avoid: physical security systems, guest management systems and a few others.

On top of that, the justification seems more like a baseless rant, citing only one blog post as a source. Ranting engineers should not make business decisions.

> I find this a fairly bad policy.

How many engineers have you worked with that ONLY worked in Windows, and did it better than anyone else...?

It's just a filter.

developers using windows isn’t necessary to test web software on browsers on windows.

Why? Gitlab is not a Windows application per se. Either you use a browser or git on the cli.

GitHub for example does have desktop apps that allow using GitHub for less CLI-inclined folks. This allows integrating people that are not primarily developers into your GitHub-based workflows with less hassle, and fosters collaboration across those boundaries.

Git for windows is also notoriously different when it comes to edge cases, so in Gitlabs place I‘d be absolutely happy to have developers that use that OS as a daily driver.

It’s somewhat rare for developers to be willing to do that though.

Absolutely, that’s why I believe you shouldn’t put up more obstacles than absolutely necessary if someone would pick windows.

Isn’t the glab cli offered on Windows? Wouldn’t you want them dogfooding that?

true

And both the browser and cli vary by platform... Quite a bit, in some cases.

> what's not used is not tested

What are they going to test on Windows? It's a web platform that runs on a Linux server... And Rails is kinda annoying to develop on using Windows, you definitely won't put it on a Windows server, what's the point?

Test that the web UI works for the large number of customers running a browser on windows?

Confirm the Windows runners work as expected?