Communication problem with the OpenWrt team

jow · January 15, 2020, 10:31am

Many (early) OpenWrt developers are Kernel contributors, hence the preference for mailing list based workflow.

The resources required to host a Gitlab instance (or a commercial Github on premise one) are considerably higher compared to hosting a mailing list, that is one of the factors contributing to the decision (aside from the initial preference on MLs due to the familiar kernel.org workflow). Using free-to-use offerings is one possibility but not seen as a viable option by all team members. I personally am against using commercially 3rd party hosted infrastructure.

On the other hand it is correct that these platforms allow for a very good integration, as long as you adapt your workflow around them.

GitHub's barrier to entry is lower which both leads to an increased amount of contributions (good), a sometimes lower quality of contributions (not good) and raised expectations from the contributor side (depending on the pov, not necessarily good either).

There seems to be, among some people, the expectation that every PR made on Github is to be quickly merged and that any change requests to an open PR (such as adding S-o-b, alphabetical sorting of entries, consistent code style, white pace cleanup) is needless churn, specifically done to put off newbies. In my perception, some GitHub contributors think that editing kernel code suddenly is easy just because it is made via GitHub.

I have seen cases where PR creators got angry and cursing the reviewer because changes were demanded to a trivial patch. Maybe it is common in some parts of the GitHub culture to submit unclean patches and let the reviewer/merger take care of sorting out the details. Maybe it is the higher barrier of entry in mailing list based workflows that leads to only very dedicated people submitting issues and thus to a higher perceived quality of patches.

In any case, a lot of manual work is required yet to merge a (non-trivial) submission, combined with scarce developer resources (both in terms of number and time). Another negatively contributing factor is the unwillingness of some developers to master another workflow.

Things we did the last months to address these issues are:

onboard more developers
work on CI and PR automation as part of the GitLab evaluation

Digging out of this hole takes time however and is not something done in a matter of weeks for a larger project, especially considering OpenWrt's organization structure of a loosely coupled team of volunteers without strict governance and planning model.

There is the ability do do GitHub PRs now (slow merges does not mean its not possible. Merges are slow on the ML as well)
The amount of releases increased
The amount of supported targets increased
The amount of developers increased (not as much as we'd like though because other long term contributors becoming inactive)
The release process, albeit not yet as fast as we'd like, was improved compared to the state before
The forum was relaunched
Hosting sponsorship was acquired
Intangible assets have been transferred to a foundation
The number of commits in the time frame May '14 to May'16 [1] (before the fork) compared to May '16 to May'19 [2] (after the fork) increased by ~60% (from ~2100/year to ~3500/year)
The number of comitters to the the repository has been increased from 17 to 28 [3] [4]
The number of different contributors, albeit not clearly attributable to the pre-fork times due to the use if SVN, substantially increased as well from ~330 to ~660 [5] [6]
The project is using Git in the first place
A dedicated build infrastructure exists to provide binaries for all branches
The website is managed by contributors and not the team anymore

There is ongoing work to refresh the project CI.