Which developer operating systems do we support?

[brainwane]

Type: code issue

Followup for #13597:

Come to think of it, we should probably create a list of platforms we wish to be supported, and then use that as a guide for which platforms we should actively work on to support.

Let's have that discussion here -- there's a bunch of relevant discussion in #13597 . I assume that we'll try to support a few recent Windows versions, a few recent versions of common Linux distributions, and a few recent Mac OS X versions; the way we do that may involve Vagrant or some other virtualization approach. And we could work on a cloud solution like what Zulip provides to some contributors as well.

[jeremyn]

We need to articulate what the goals are here or this will just be people spitballing popular and/or their personal favorite OSes.

We also need to decide what "supported" means. To me, supported means up-to-date documentation, automated tests, and someone at the EFF who is willing to help a contributor with their build error. (You can't rely on volunteers here since volunteers are free to ignore issues if they want, and that's not support.)

I also presented some alternative ideas in https://github.com/EFForg/https-everywhere/issues/13597#issuecomment-347620780 to increasing the number of potential contributors besides just increasing the number of supported platforms. It would be nice to get feedback on that. (Another alternative I didn't suggest there is for the EFF to simply run its own public server and give out shell access to established contributors who want it. This has some potential problems but might be cheaper overall than requiring @Hainish to do tech support.)

[wonderchook]

@jeremyn in your comment what path are you thinking to be more Windows friendly? Doing something other than WSL for development?

I've worked a lot in emerging economies and almost everyone was running Windows, though I think with clear instructions the WSL path wouldn't be too bad. That said if someone was in a low bandwidth environment it might be annoying to download.

[jeremyn]

@wonderchook WSL works for people using Windows 10 with reasonably good equipment/internet access who are familiar with Linux. I suppose most of these people are also capable of creating a VM, setting up a VPS, dualbooting Linux, or at least capable of figuring out how to do one of those things. So WSL support isn't about enabling access to people who couldn't participate before, but reducing their barrier to entry (aka enabling their laziness if you want to be uncharitable about it).

People with very low resources (ancient computer, Windows XP/Vista, shared and expensive dial-up) should probably be steered toward cloud/remote development, or the CodeMirror tool with GitHub for ruleset work. I'm interested in your thoughts here, especially with your expertise in emerging economies.

Native Windows support could encourage participation by people with low and/or Windows-only tech knowledge who have access to good equipment/internet access. On one hand, more participation sounds good, but on the other hand I'm concerned about attracting people who will need heavy guidance on basic stuff like git commands. Some technical knowledge should be assumed.

There's an issue (https://github.com/EFForg/https-everywhere/issues/5101) discussing making HTTPS Everywhere available for Edge. I don't know how Edge extension development works but it might require native support.

[wonderchook]

@jeremyn in the areas I've worked people had cheap, but pretty new laptops rather than ancient ones. That was why I was thinking at least in some places they would be more inclined to have Windows 10.

I'm not against the idea of Native Windows support, though I was picturing it would require a complete rewrite of the install script. As you mentioned the expectation of people having some basic technical knowledge was making me think they could handle WSL or other options.

I was reading through the Edge discussion, prior to it I had not actually ever opened Edge. So I don't know much about developing on it.

[jeremyn]

I'm not in favor of either WSL or native Windows development, as I've said before, with the possible exception of enabling Edge development if native support is required for that to happen. This project is full of half-developed/half-supported/abandoned stuff, I don't want to add to that list. The best hope of getting something well-supported is to funnel everyone into the same dev environment.

It's maybe worth noting that @Hainish, the primary person here, literally did not have a Windows system available to test with as of this week and had to order one (https://github.com/EFForg/https-everywhere/issues/13731#issuecomment-348056975). This is not a good sign for what Windows support would look like in, say, a year.

[jeremyn]

Amazon recently announced their AWS Cloud9 service.

AWS Cloud9 is a cloud-based integrated development environment (IDE) that lets you write, run, and debug your code with just a browser. It includes a code editor, debugger, and terminal. ... AWS Cloud9 gives you the flexibility to run your development environment on a managed Amazon EC2 instance or any existing Linux server that supports SSH.

Maybe we want to look into this, or some other cloud development environment.

[Hainish]

@jeremyn said:

It's maybe worth noting that @Hainish, the primary person here, literally did not have a Windows system available to test with as of this week and had to order one (#13731 (comment)). This is not a good sign for what Windows support would look like in, say, a year.

I expect our backend dependencies not to shift much here. Once we have established a build process for a specific platform, it should only require maintenance if our dependency graph changes, or the underlying build system becomes out of date. So forming a cost-benefit analysis on OS support should account for this as a factor.

That being said, I'm not convinced we should support Windows, and was intending to use the Windows device to test proper operation of the ruleset debugger (#13731) which does not require building from source. I don't have much of an opinion about supporting Windows as a development environment. Rulesets can now be debugged and written from the extension itself.

While most people in the world are using Windows as their desktop OS, I don't see it in high usage as an open-source development platform. @wonderchook has pointed out that this might be a self-perpetuating problem, so there is that factor as well. I'm inclined to give support for Windows via WSL a good-faith try, assessing how difficult it will be to build support. Taking an initial shot at it should at the very least reveal how difficult it will be, and we can re-evaluate from there.

[wonderchook]

Development using Windows 10 with WSL works already. I had one little snag when I tried it, but that was because I git cloned into Windows. dos2unix and then it worked. I think the only specific recommendation I would make for using this method is to run git directly within the sublinux system rather than in Windows itself.

[jeremyn]

I've made my position pretty clear and don't really want to keep going on about it. I think anyone who proposes supporting a new OS should also describe how they are going to make sure contributors don't encounter the sorts of problems I did with Fedora described in https://github.com/EFForg/https-everywhere/pull/5584#issue-163039124 and https://github.com/EFForg/https-everywhere/issues/5628#issue-165114971, not just immediately after support is added but also a year or two later on.

[jeremyn]

FYI, I created a Docker configuration for HTTPS Everywhere development at https://github.com/jeremyn/https-everywhere-docker-environment. It works on an Ubuntu 16.04 system, but hangs on a Windows 10 system. I don't know about macOS.

It's not perfect, but I think Docker is probably the "2018 way" of doing cross-platform development.

[Hainish]

Discussion in https://github.com/EFForg/https-everywhere/issues/6749 has shed some new light on this discussion. Due to our need to support python 2.7/3.6 concurrently, as well as a lot of the good points that @jeremyn raised, I'm changing my thinking on this. We should solidify on one developer environment rather than trying to spread our efforts too thin and support multiple shifting environments.

As per the discussion in #6749, the latest Ubuntu (17.10) is the only release of Ubuntu or Debian that currently supports python 3.6 via the package manager. Our CI is run in a Ubutnu trusty environment that has make 3.6 available. If we want to make a decision right now, I think Ubuntu 17.10 is a solid target. Otherwise, we can punt on this until April, when Ubuntu 18.04 LTS is released. This has the advantage of long-term support. We could also just target for Ubuntu 17.10 for the next few months, then transition to 18.04 when it is released.

[jeremyn]

I didn't realize that a migration to Python 3.6 also meant a migration to Ubuntu 17.10.

If by supporting Ubuntu 17.10 you mean un-supporting everything else -- and not just un-supporting, but rather, making a change that will definitely break something for people who haven't prepared -- when are you planning to make that change, and what specifically will break?

[Hainish]

@jeremyn it doesn't necessarily mean migration to Ubuntu 17.10, it's just the easiest way to recommend setting up a dev environment that is officially supported. I have debian 8 as my environment, having compiled py3.6. It works fine.

In answer to your question "what specifically will break" for those that don't have 3.6 installed - by definition, moving forward, any scripts that have been converted to py3.6.

[Hainish]

In answer to your question "what specifically will break" for those that don't have 3.6 installed - by definition, moving forward, any scripts that have been converted to py3.6.

Right now this is only ./make.sh and ./utils/zipfile_deterministic.py but I'm going to be dedicating more time to py3.6 conversion.

[jeremyn]

@Hainish At the moment it doesn't mean much to say we officially support one OS/version over another, other than whatever we use for CI testing. So if the issue is just Python 3.6, we can just say "you need Python 3.6 to build the extension" and maybe give some hints on how to do that for various OSes. There's no immediate need to recommend 17.10. When 18.04 comes out it will be much easier to recommend, since it is an LTS.

[Hainish]

For some closure here, let's punt on this until April, when 18.04 comes along. At that point we can formalize our decision and add it to CONTRIBUTING.md.

[jeremyn]

It's a rule of thumb not to rely on a new LTS version until the first point release, that is, 18.04.1. The do-release-upgrade utility doesn't prompt to upgrade the OS until the first point release is available. Ubuntu 16.04.1 was released in July 2016, so I suppose 18.04.1 will come out in July this year. There is some risk with jumping to 18.04 in late April. I'm not saying we should wait until July, probably at least until May.

The Python 3.6 upgrade has been troublesome because it's not readily available in the current de facto primary platform, Ubuntu 16.04, used by CI. Ideally the decision making process should have been reversed: choose a single platform, see what it comes with, and target that. So going forward I hope that we stick with Python 3.6 until either (a) Ubuntu 18.04 comes with something different, or (b) we choose a different primary platform, such as Ubuntu 20.04, and even then not upgrade Python until after the new platform has been publicly released. This goes for other dependencies too, not just Python.

[Hainish]

@jeremyn the do-release-upgrade script is intended to upgrade an entire server environment, which entails much more complexity and failure points than a fresh installation. Ubuntu promotes new releases very quickly, and should be considered stable. I don't know where you're getting this "rule of thumb" from, other than a single-serving upgrade script.

The Python 3.6 upgrade has been troublesome because it's not readily available in the current de facto primary platform, Ubuntu 16.04, used by CI.

Travis makes Python 3.6 available for their trusty build environment by specifying it, as we do in https://github.com/EFForg/https-everywhere/blob/65eac6c9c84627d374c185dbd88b644735444652/.travis.yml#L5. It's as simple as that. For tests performed in docker, we've migrated to ubuntu:artful: https://github.com/EFForg/https-everywhere-docker-base/blob/master/Dockerfile#L1, which has Python 3.6 available via the package manager.

Ubuntu 17.10 already has Python 3.6 available, and 3.7 stable won't be released until June: https://www.python.org/dev/peps/pep-0537/. Ubuntu 18.04 will come with Python 3.6 available via the package manager.

The reasoning for choosing Python 3.6 was explained in https://github.com/EFForg/https-everywhere/issues/6749, where I solicited feedback. Let's keep the discussion there.

[jeremyn]

It is commonly understood that a new version of any OS can be flaky immediately at launch. There is some risk in jumping to 18.04 right away, for this reason. Ubuntu's own do-release-upgrade recognizes this by delaying until the first point release.

(There was actually a problem just recently where Ubuntu 17.10 was messing with people's BIOSes, and Ubuntu pulled the download from their main site until they released 17.10.1. This would not have affected us, but it does show that Canonical's QA is not perfect.)

I'm not talking about the merits of Python 3.6 vs 2.7 or whatever, but what it means for dependencies in general once we choose a primary environment. The environment should determine the dependencies and not the other way around, and we should avoid changing environments that often. For example we should consider following Ubuntu's LTS cycle of 18.04 to 20.04 etc, and not switch to Ubuntu 18.10 (or 19.04 or 19.10) just because it comes with some newer version of Python, or something else, that has features we would like to have but don't absolutely require.

[Hainish]

It is commonly understood that a new version of any OS can be flaky immediately at launch. There is some risk in jumping to 18.04 right away, for this reason. Ubuntu's own do-release-upgrade recognizes this by delaying until the first point release.

The fact that there will be some minor problems with releases doesn't imply that we should stray away from these for development. Problems and vulnerabilities can arise at any point, the more fundamental structural goal is to maintain enough flexibility so that we can pivot when these do arise. I don't think anyone is suggesting switching to a non-LTS build as a long-term commitment. The plan is to have all our builds standardize on 18.04 LTS.

Speaking of the theoretical primacy of (1) the development environment or (2) the targeted python version seems curious to me, given that as of 18.04 (as well as the interstitial 17.10 that we're using now) no dissonance between the two exists. I'm well aware that 18.04 LTS will support 3.6, this is one of the considerations we discussed in the Python 2->3 discussion.

[jeremyn]

Again, all I'm saying is that there is some risk in jumping over right away. Maybe you will switch everything over the day after 18.04 is released and then spend a week debugging problems that Canonical will fix themselves. Or, maybe it will work just fine. It is up to you now as far as I'm concerned, based on your schedule and preferences and willingness to take on that risk.

As of 18.04, yes, Ubuntu and our Python will be in sync. I'm talking about going forward, the dependency should be controlled by the OS, and the OS should be stable. This time around the migration to Python 3.6 forced a temporary jump through 17.10 for a few months, and ideally we would have avoided that.

[Hainish]

Since the specific question "Which developer operating systems do we support?" is resolved, though the question of "when" we will support them remains open, I'm closing this issue.

We may want to formalize a process of when we move to the latest LTS at some later time. This decision doesn't need to be made immediately, though, since the LTS release cycle happens once every two years. We could also choose to move to the latest LTS manually after some discussion, though this would lack the advantage of expectation-setting. I consider flexibility here a more desirable property.

[jeremyn]

Not to reopen the issue but just to make an observation:

I'm not sure what we achieved here, other than making the circular statement that we support Ubuntu 17.10, because that's what CI uses, because that's what we support. In practice, as far as I know, none of the maintainers actually use Ubuntu 17.10 as their primary dev environment for HTTPS Everywhere: I use an Ubuntu 16.04 VM mostly prepared with Ansible, and additionally with Python 3.6 built from source; @Hainish uses Debian 8; @brainwane uses Debian 9; @wonderchook uses Ubuntu with WSL; I don't know about @gloomy-ghost or @J0WI or the various regular contributors. So insofar as shifting policy and intention was a goal for this issue -- that is, changing what we ought to be doing, rather than just describing what we are currently doing -- then I'm not sure how much of that goal has been achieved.

[brainwane]

Personally, I primarily opened the issue to find out the status quo -- precisely, as you said, to describe what we are currently doing. So I hope that makes you feel better!

[jeremyn]

@brainwane Your opening comment quoted @Hainish from https://github.com/EFForg/https-everywhere/issues/13597#issuecomment-346217114 about "a list of platforms we wish to be supported" (italics from the original), which goes beyond the status quo.

Anyway I'm okay with closing this issue if we just don't want to talk about it anymore right now, but I'm not sure we can say the question was answered, partly because it's not clear what the question was. For example see my comment at https://github.com/EFForg/https-everywhere/issues/13815#issuecomment-348049844 where I wrote 'We also need to decide what "supported" means.', and we never did that. (And I don't really want to go into it anymore now, either.)

[pipboy96]

I personally use Arch Linux, and the only issue I have encountered is that in many places python3.6 is hardcoded, while Python 3.7 is installed by default. @Hainish @zoracon can this be changed to simply python3 or is there a specific reason to use an old version?

[Hainish]

I would hardly consider Python 3.6 an old version - it will be supported until the end of 2021.

zipfile_deterministic.py, which ensures that Firefox builds are deterministic, is derived from the Python 3.6 standard library. We've targeted 3.6 for this reason, as well as to enforce similar tooling across different contributor development environments. This may well run perfectly on Python > 3.6, but there is a maintenance burden of determining that and fixing it. And this is unnecessary since docker allows you to pull python:3.6 from Dockerhub to perform this build.

[pipboy96]

I would hardly consider Python 3.6 an old version - it will be supported until the end of 2021.

That's arguing semantics, but you are right.