Chromium on unsupported platforms?

[Matthew Dempsky]

A handful of issues labeled OS-OpenBSD were recently closed as WontFix, "OpenBSD is not a supported platform for Chromium."  It seems somewhat inconsistent that the Chromium source tree contains code to support OpenBSD and other unsupported platforms like FreeBSD, Solaris, and QNX; but the issue tracker can't be used to track bugs relating to them.

Can we harmonize things and establish how unsupported platforms that are still interested in running Chromium should interact with the project?

A couple options I see:

1. Let the issues continue to be filed/tracked in the Chromium issue tracker.  If they don't get fixed in a timely manner, they can get closed for inactivity like all the other stale bugs filed even for supported platforms.

2. Remove OS_OPENBSD, OS_FREEBSD, etc. and all mentions of them from the source tree.  Those changes can be maintained in a separate branch/repo, and issues can be tracked there too.

Note: FreeBSD and OpenBSD already maintain a bunch of patches to make Chromium build/run on them:

    http://svnweb.freebsd.org/ports/head/www/chromium/files/

    http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/chromium/patches/

I can't imagine Chromium builds on Solaris or QNX any more cleanly.

2b. Allow code to remain as long as it's tested by a buildbot.  E.g., if FreeBSD and OpenBSD buildbots were configured to run base_unittests and gn_unittests (and they stayed green), then code to support them in base and tools/gn could stay in tree.  Code in other directories gets removed and may be restored if appropriate buildbot test coverage is added.

Note: FreeBSD and OpenBSD both run on Compute Engine, which is what the Go project currently uses for its {free,open}bsd/{386,amd64} builders.

[Nico Weber]

https://groups.google.com/forum/#!topic/chromium-dev/bylfVv51om0 is the discussion about adding the first of these ports. Bug tracker use wasn't discussed back then. I think there was a follow-on discussion on this that made the point that everyone should understand that these ports are volunteer-run and shouldn't impose a cost on "official" ports, but I can't find that thread right now. One potential risk with having bugs for these in crbug is that these might get assigned to non-volunteer folks somehow and the assignee might not be aware that this isn't an "official" port (not too unlikely, given the many build configs we do support these days). Other than that, 1 doesn't seem horrible to me.

If the in-tree support for these builds is so bitrotted that it needs 323 patch files already anyway, then it seems like people working on this nowadays aren't doing this in-tree, so option 2 might be fine? That part is probably best answered by the people working on these platforms (if any).

2b is something we explicitly said we didn't want in that thread I can't find the link to.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Matthew Dempsky]

On Wed, Oct 7, 2015 at 7:43 PM, Nico Weber <tha...@chromium.org> wrote:

2b is something we explicitly said we didn't want in that thread I can't find the link to.

If you can find that thread, I'd be interested in reading it.  I assume the explicitly unwanted aspect was running test infrastructure for unsupported platforms?

[Thiago Farina]

Matthew, I would be happy if we could provide full support for FreeBSD.

--

Thiago Farina

[Anthony LaForge]

Hey Matthew,

Thanks for raising this thread.  Nico's response was perfect, and largely reflects my own thoughts on this topic.

Though we don't formally consider BSD to be a supported platform, there are occasions when we'd work w/ third parties to upstream some patches into Chromium, for cases where it is practical and doesn't create a maintenance burden (i.e. a third party did the work, and we'd review it for fit and fitness).  Despite this, we explicitly have not sought out (or tracked) work to expand the current set of supported platforms, since fully supporting a platform has a number of implications (e.g. developer/ staff commitment, test coverage, infrastructure, etc...), which we currently can't commit to.  Having such work items attached to our project/ issue tracker implies a level of support/ commitment that simply doesn't exist (i.e. we don't want to mislead anyone).

To that end, I'd rather keep issues related to those ports at an arms length, with work tracked in downstream projects, by the people who maintain the ports... permitting reasonable upstreaming where possible.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Matthew Dempsky]

I find it highly unlikely that the 6 OS-OpenBSD issues in the issue tracker is more likely to mislead people into thinking OpenBSD is an officially supported platform than the 78 Chromium source files that mention OS_OPENBSD.  Not even all of those OS-OpenBSD issues are really OpenBSD specific:

crbug.com/380968 turned out to be a real bug in GN's unittests, and they were just flakier on OpenBSD because its ASLR is more aggressive than other platforms. 

crbug.com/381015 is another likely OS-agnostic issue that I happened to be able to reproduce on OpenBSD because of CPU scheduler behavior differences.

crbug.com/381405 is tagged OS-Linux *and* OS-OpenBSD because it affects both.

It seems like an easier way to clarify supported platforms would be to have an official porting policy and identification of "first class ports" like the Go project does (https://github.com/golang/go/wiki/PortingPolicy) so people don't have to infer.