-
Notifications
You must be signed in to change notification settings - Fork 232
Add Android Workgroup charter and membership list #925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
abe9efa
93b1c90
468279c
e27d8ee
5ea492f
99968c9
921391b
f9eabb5
7e12133
d275541
4cac6a6
2c52bc2
276ce32
6744c26
2b8db54
8f6f0fa
d3906b6
0021d38
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
- name: Abe White | ||
handle: aabewhite | ||
github: aabewhite | ||
affiliation: | ||
|
||
- name: Andrew Druk | ||
handle: andriydruk | ||
github: andriydruk | ||
affiliation: | ||
|
||
- name: Finagolfin | ||
handle: finagolfin | ||
github: finagolfin | ||
affiliation: | ||
|
||
- name: Jason Foreman | ||
handle: threeve | ||
github: threeve | ||
affiliation: | ||
|
||
- name: Joannis Orlandos | ||
handle: Joannis_Orlandos | ||
github: Joannis | ||
affiliation: | ||
|
||
- name: Luke Howard | ||
handle: lukeh | ||
github: lhoward | ||
affiliation: | ||
|
||
- name: Marc Prud’hommeaux | ||
handle: Marc_Prud_hommeaux | ||
github: marcprux | ||
affiliation: | ||
|
||
- name: Robbert Brandsma | ||
handle: obbut | ||
github: obbut | ||
affiliation: | ||
|
||
- name: Saleem Abdulrasool | ||
handle: compnerd | ||
github: compnerd | ||
affiliation: | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
--- | ||
layout: page | ||
title: Android Workgroup | ||
--- | ||
|
||
The Android Workgroup is a team that promotes the use of Swift for developing Android applications. | ||
|
||
## Charter | ||
|
||
The main goal of the Android Workgroup is to add and maintain Android as an officially supported platform for the Swift language. | ||
|
||
The Android Workgroup will: | ||
|
||
* Coordinate the development of a reference Swift Android SDK | ||
* Improve and maintain Android support for the official Swift distribution, eliminating the need for out-of-tree or downstream forks | ||
* Recommend enhancements to core Swift packages such as Foundation and Dispatch to work better with Android idioms | ||
* Work with the PSG to officially define platform support levels generally, and then working towards achieving official support of a particular level for Android | ||
marcprux marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* Determine the range of supported Android API levels and architectures for Swift integration | ||
* Develop [continuous integration](https://www.swift.org/documentation/continuous-integration/) for the [main Swift repository](https://ci-external.swift.org/job/oss-swift-RA-linux-ubuntu-24.04-android-arm64/) that adds Android checks for pull requests | ||
* Identify and recommend best practices for bridging between Swift and Android's Java SDK and packaging Swift libraries with Android apps | ||
* Develop support for debugging Swift applications on Android | ||
* Advise and assist with adding support for Android to various community Swift packages | ||
|
||
## Communication | ||
|
||
The Swift Android workgroup uses the [Swift Android forum](https://forums.swift.org/c/development/android) for general discussions. It can also be contacted privately by messaging [@android-workgroup](https://forums.swift.org/g/android-workgroup) on the Swift Forums. | ||
|
||
If any significant decisions are reached during one of the workgroup’s regular meetings, a member will post about them in the Forums within one week. The outcome of each proposal review will be announced by its review manager in a separate thread dedicated to that proposal. | ||
marcprux marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Membership | ||
|
||
Membership in the Android Workgroup is contribution-based and expected to evolve over time. Adding new members and removing inactive ones is subject to a vote by the existing members and requires unanimous agreement. Membership is limited to ten members in total to keep the group small enough to be effective. A cap of two members per company is in place to avoid over-representation. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We’ve added this to the agenda item for the core team meeting next week. @compnerd or I will provide an update soon. |
||
|
||
The Core Team selects one member of the workgroup as the chair. The chair has no special authority over the workgroup, but they are responsible for ensuring its smooth functioning, including by: | ||
|
||
* organizing and leading regular meetings, | ||
* ensuring that the workgroup communicates effectively with the community, and | ||
* coordinating meetings between workgroup representatives and other Swift workgroups or teams when necessary. | ||
|
||
If you would like to join the workgroup, send a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=android-workgroup) on the Forums and you will be invited to the next available group meeting to discuss it more. See Community participation for examples of ways to contribute and demonstrate your interest to the group. | ||
|
||
Workgroup members will try to make a decision independently by consensus whenever possible, and will raise issues to the Core Team when there are particular challenges with reaching consensus on significant decisions. | ||
marcprux marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The current members of the Android Workgroup are: | ||
|
||
{% assign people = site.data['android-workgroup'].members | sort: "name" %} | ||
<ul> | ||
{% for person in people %} | ||
<li>{{ person.name }} | ||
{%- if person.affiliation -%} | ||
, {{ person.affiliation }} | ||
{% endif %} | ||
{% if person.handle %} | ||
(<a href="https://forums.swift.org/u/{{person.handle}}/summary">@{{person.handle}}</a>) | ||
{% endif %} | ||
</li> | ||
{% endfor %} | ||
</ul> | ||
marcprux marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Meetings | ||
|
||
The Android Workgroup meets biweekly on Wednesday at 2:00PM ET (US Eastern Time). The meetings take place in the weeks with the [odd week numbers](http://www.whatweekisit.org/). | ||
|
||
Many workgroup meetings are meant for open discussion and any Swift community member may attend by sending a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=testing-workgroup) beforehand to request an invite. Some meetings are reserved for private discussion by group members, for example to make a decision on a proposal under review. | ||
marcprux marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Community Participation | ||
|
||
Everyone is welcome to contribute in the following ways: | ||
|
||
* Participating in design discussions. | ||
* Asking or answering questions on the forums. | ||
* Reporting or triaging bugs. | ||
* Submitting pull requests to any of the Android support library projects. | ||
* Discuss ideas on the Swift Forums. You can create new topics in the [Android](https://forums.swift.org/c/development/android/115) category, or add the android tag to any topic. | ||
* Develop new tools to aid the Android experience or improve existing ones. | ||
* Provide feedback to the members of the Android Workgroup directly by sending a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=android-workgroup) on the Forums. The workgroup chair brings outstanding issues and topics to the workgroup to discuss during regular meetings. The workgroup decides the actions for the issues. | ||
* Join the Android Workgroup’s regular video meetings. Send a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=android-workgroup) to request access, since calls are easier to manage when kept to a relatively small number of participants. | ||
marcprux marked this conversation as resolved.
Show resolved
Hide resolved
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be happy to make that change. @al45tair, what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't go into detail, but Swift is in use on more than just Android smartphones.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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":
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm convinced. I've changed "forks" to "patches".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.