Add Android Workgroup charter and membership list

[marcprux]

Motivation:

From the discussion at https://forums.swift.org/t/swift-on-android-working-group/77780/25 and in messages with @al45tair, this PR adds the Android WG charter for review by the Core Team and eventual publication to swift.org.

Modifications:

• Add the charter document at android-workgroup/index.md
• Add _data/android-workgroup/members.yml listing the members
• Add a navigation entry to _data/navigation.yml

Result:

The Android Workgroup charter and membership will be published to swift.org

[marcprux]

CC: @aabewhite, @andriydruk, @finagolfin, @threeve, @Joannis, @lhoward, @marcprux, @Obbut, @compnerd

[finagolfin]

Is anybody actually doing this? I think in-tree support is pretty good now, with downstream mostly just applying a few patches, ie nobody is maintaining an actual fork to my knowledge.

[marcprux]

Agreed that I don't know of anyone currently doing this. This specific point was requested by the PSG. I suspect – and perhaps one of them might confirm – that the goal is for the official Android SDK to be sufficiently adaptable to multiple Android environments (smartphone, embedded, car, TV. etc.) so as to make it unnecessary for a fork to have be created to support such an environment.

[finagolfin]

As far as I know, nobody has ever tried Swift on anything other than Android smartphones, so if those other Android environments require more work, nobody has even started on that.

I suggest you change "forks" to "patches", as that more accurately characterizes where the Android platform support is today for the dominant smartphone usecase, ie nobody has needed a fork in awhile.

[marcprux]

I'd be happy to make that change. @al45tair, what do you think?

[etcwilde]

I can't go into detail, but Swift is in use on more than just Android smartphones.

[finagolfin]

My only point is that Android support is in pretty good shape now, such that no forks are needed. I currently have to modify only a handful of lines in the stdlib and corelibs to have a working trunk Android SDK against the oldest API allowed for Play Store updates, with a dozen or so more lines if I want to support really old Android APIs or libTesting, as that new test library was just added with Swift 6 and I just added it to my Android SDK bundle.

I don't think Android TV or other environments require much else, and if something exotic like certain embedded kiosks or whatever do, right now nobody has heard of public Swift forks for that. I think you have an incorrect impression of what other Android environments require because of your experience mostly with Darwin platforms, which may be more differentiated, as I've heard of people running broad tests for their natively-compiled, ie non-Java/JVM, code that worked well on smartphones subsequently on Android watches without a problem.

Literally nobody has suggested not accepting Android TV patches: what I said is that either nobody has tried that or AFAIK nobody has required a public fork for that yet.

This is just about keeping this line accurate and setting expectations: Android support currently requires a few patches to upstream, not a fork, at least that I know of.

[etcwilde]

Maybe I misunderstood. I was mostly responding to this comment which I interpreted as "we don't need to care about the other uses of Android":

As far as I know, nobody has ever tried Swift on anything other than Android smartphones, so if those other Android environments require more work, nobody has even started on that.

I put Swift 5.6 on the television and were some bus errors due to unaligned memory accesses in the runtime. I believe that most of them were patched by the time of the Swift 5.9 release. I don't know if anything new has slipped in since.

[finagolfin]

Oh, that's interesting, haven't heard too much about people trying other languages on Android TV, as I think they're more restrictive in what apps you can install there too.

My only point with this suggestion is that the Android support is in pretty good shape in trunk already and we take patches in quickly, so public forks haven't been needed, to my knowledge. I think I have a pretty good idea of where it's at, as I suspect I'm the only person in the world who's been regularly running most of the same Swift toolchain tests that are run on the official linux CI but natively on Android, ie the compiler validation suite plus all the corelibs tests up to the SwiftPM and sourcekit-lsp tests, on a monthly basis for most of the last six years (hopefully we can soon get them running more regularly on the official CI too, swiftlang/swift#79185).

Changing this line to say "patches" signals to interested readers/users how far along this port has already come, but of course, any further testing and support for more niche Android uses is welcome.

[marcprux]

I'm convinced. I've changed "forks" to "patches".

[al45tair]

I don't think it's hugely important whether it says "forks" or "patches"; the point is to make clear that Android support belongs in the main source tree, and not as some kind of side-project. i.e. it is explicitly a goal for this Working Group that the main Swift distribution has Android support.

[al45tair]

@etcwilde You should probably look over this also.

[etcwilde]

I was under the impression that steering groups had membership limitations but workgroups were supposed to be open to anyone who wants to contribute to that area. @shahmishal or @al45tair, correct me if I'm wrong.

[finagolfin]

We discussed this on the call with Mishal a month ago. We simply copied this text from the similar SSWG and Testing workgroup charters, so I think we're fine with further discussion on how to structure this Android workgroup.

We thought some member limitation would be helpful for us too, since some of our work is similar to a steering group, but I don't think we've really hashed it out.

[shahmishal]

We’ve added this to the agenda item for the core team meeting next week. @compnerd or I will provide an update soon.

[al45tair]

We've reviewed the Charter and discussed it with Core Team, and would like a few changes made before it gets approved. In particular, please bear in mind that

1. The purpose of a Workgroup is to encourage community members to participate in work that is of interest to that Workgroup, and restricting membership or access to meetings runs counter to that purpose.
2. A Workgroup should not be running a review process or making significant decisions that affect Swift; that is the function of the Swift Evolution process and the Steering Groups respectively. If the Workgroup has a proposal that has a significant impact on Swift in some way, it should be pitching it on the forums in the usual manner, and coordinating a review with the appropriate Steering Group(s).

[finagolfin]

@al45tair, thanks for the feedback. Regarding the language in this workgroup charter that you disliked, I noted last month that we directly copied it from the SSWG and Testing workgroup charters, which I had asked Marc to do.

I am fine with the changes you suggest, prefer it in fact, but you cannot say this language broke some workgroup precedent, when most of the workgroup charters appear to limit their membership in the same way.

[al45tair]

@al45tair, thanks for the feedback. Regarding the language in this workgroup charter that you disliked, I noted last month that we directly copied it from the SSWG and Testing workgroup charters, which I had asked Marc to do.

I am fine with the changes you suggest, prefer it in fact, but you cannot say this language broke some workgroup precedent, when most of the workgroup charters appear to limit their membership in the same way.

I did not, in fact, say that it broke precedent, and I appreciate both that some existing workgroups do have restrictions on their membership, and that the text in question was copied from their charters.

Notwithstanding that fact, it is the case that we (Core Team and the Platform Steering Group) consider that such restrictions on workgroup membership are undesirable, both in general and in the specific case of this workgroup, which is the opinion I was asked to express.

[marcprux]

I've made the requested changes.

@al45tair, if you think the changes satisfy the concerns raised by the Core Team & PSG, can this get merged without further ado? I worry about another ~3-month delay in getting feedback from the teams.

[finagolfin]

Except for escalation nit, looks good, thanks for putting this together, Marc.