Switch issues and CI to GitHub

Tue Jan 25 22:59:32 PST 2022

On Thu, Jan 20, 2022 at 10:42:15AM +0100, Paul Spooren wrote:
>> Must confess: I was unaware of the ~16k issue body character limit...
> 
> I discussed this with Drew (sourcehut developer)

Thanks!  That means there's a chance it will be documented and, if
possible, fixed/improved.

Incidentally, is this limit actually a problem for OpenWRT?  (E.g. what
% of bug reports would be affected?)

>> # BROKEN HANDLING OF USER ACCOUNT DELETIONS
>>
>> [...]
> 
> I think they are in a bit of a pickle there.

Yes, GitHub messed up there.

> If you delete everything a lot of issues miss comments and stop making
> sense.

Indeed.  That would not be best practice at all, nor did I suggest it as
a solution.

> If you rename the the user account “aparcar” to a random string like
> “mystery-blob-64”, other users can still “recreate” the deleted user
> behavior by specifically looking for that _new_ name.

Yes, best practice solution 2 is not *perfect*.  But it's still a better
solution than GitHub's current approach.

Under solution 2, only people who already knew the original username of
the contributor would be able to connect that username to the new one.
(Anyone else would have to rely on those people, rather than GitHub, to
make the connection.)  Those people would have been aware of the
original username's contributions anyway, so they would not gain any new
information from GitHub as a result.  (I.e. the user who had left GitHub
would not suffer a reduction in privacy.)

So, if GitHub followed solution 2, then GitHub would be upholding its
legal responsibilities (e.g. GDPR Article 17 "right to erasure", etc).
Especially if, having performed the replacement of the old name with the
new one in all instances, GitHub then deleted its internal record of the
connection between the old and new usernames.

> Their solution seems to combine “anonymity" with usability (aka not
> ruining issue discussions entirely).

Alas, no.  GitHub's solution combines:

-   *haphazard pseudonymity* (since the original username still appears
    in at-mentions, thereby potentially breaching GDPR Article 17, etc),
    and

-   *incomprehensibility* (both because "ghost" users can't be
    distinguished from each other; and because former users are referred
    to as "ghost" in some places and by their original usernames in
    others, even within the same thread).

>> Worse still, because GitHub is proprietary and doesn't have a good
>> way for users to report GitHub bugs or submit patches to fix them,
>> bugs like this tend to go undiscussed and unfixed for years, leading
>> to progressive corruption in GitHub discussions.
> 
> They have a forum[0] and a “Discussion” thing[1]
> 
> [0]: https://github.community

OK, that's moderately new.  (Just over 4 years old:
https://github.blog/2017-11-01-connect-with-developers-around-the-world-on-the-github-community-forum/
.)

It doesn't seem to be searchable.  (At least not for some users.)

Nor does it seem possible to post there without an account - and sign-up
is unavailable for some users.

> [1]: https://github.com/github/feedback/discussions

OK, seems that's even newer.  (Only just over a year old:
https://github.com/github/feedback/commit/7f7cc0d63333934fba7acc211f19a430b49f026e
.)

Again, it does not seem to be possible to post there without an account,
and again, sign-up is unavailable for some users.

>> # BROKEN SEARCH
>> 
>> [...]
> 
> This critique came up multiple times, are you aware of a better search
> implementation?  I’d be keen to find something better.  From my
> experience bugs.openwrt.org (aka flyspray) doesn’t do a much better
> job here.

Two counterarguments:

-   IME, Flyspray's search is far better than GitHub's.   I haven't
    encountered search bugs in Flyspray like the one I kept encountering
    at GitHub.

    Can you give an example of a Flyspray search bug that is as severe?

-   Also, GitHub's issue/PR search bugs can't be fixed by users.  Nor
    has Microsoft shown interest in fixing the one I mentioned.  So that
    bug will continue impeding projects that depend on GitHub for
    issue-tracking or PRs.

    Any reasonably mature free software bug-tracker is an improvement
    over GitHub in this regard.

>> # ACCESSIBILITY, PRIVACY, AND ETHICS PROBLEMS
>> 
>> As previously discussed, e.g.:
>> 
>> https://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037546.html
>> 
>> Understand that moving OpenWRT's issue-hosting to GitHub would make it
>> impossible for some users to subscribe to OpenWRT's bug tracker to
>> receive bug reports by email.
> 
> I’m not familiar with Internet connectivity in Syria, Crimea and North
> Korea, do you know if sr.ht and codeberg.org are reachable from over
> there?

The point isn't about whether governments of those territories block
users from access to GitHub (or SourceHut, or Codeberg, or whatever).

It's about whether the site owners (Microsoft; sr.ht LLC; Codeberg e.V.)
prevent people in those territories from using some or all features of
their sites.

I asked SourceHut and Codeberg maintainers about their policies.

-   SourceHut says it complies with US and EU law, including sanctions.
    People subject to US or EU sanctions can't make *payments* to
    SourceHut, but are otherwise unaffected.

-   Codeberg says it complies with EU law, does not geoblock users, and
    is not aware of any current law requiring it to do so.

    (N.B.  Codeberg, being based in the EU, is not subject to US laws.)

So, both platforms seem to be as good as or better than GitHub on this
front.

> If a user _watches_ a GitHub project every new issue and response is
> send via email, is that an option?

Definitely not for anyone unable to register on GitHub - and possibly
not even for some people who can register, depending on accessibility
issues, sanctions, etc.

> Since I plan to have Issue Backups anyway, I could publish them
> somewhere.

Thank you!  An accessible, read-only public backup is probably a good
idea in any case.

>> Also remember, Microsoft is a key player in the surveillance-industrial
>> complex:
>> 
>> https://www.theguardian.com/technology/2016/may/02/google-microsoft-pact-antitrust-surveillance-capitalism
>> 
>> https://theintercept.com/2020/07/14/microsoft-police-state-mass-surveillance-facial-recognition/
>> 
>> 
>> Sure, comments on OpenWRT issues might be public, but do you really
>> want OpenWRT users giving Microsoft their browser fingerprints or IP
>> addresses in order to participate?
> 
> You can use their CLI (`gh`) you can also avoid using a browser.

`gh` isn't much use without an account.

Looking at the documentation, it doesn't seem possible to create an
account via `gh`.

>> (You might say: users can work around this by using Tor.  But can
>> they?  What if they live in jurisdictions where Tor usage would get
>> them flagged by law enforcement?  What if GitHub blocks sign-ups from
>> Tor?  And do you really want a situation where people have to weigh
>> up their threat models and what steps to take to protect themselves
>> from OpenWRT infrastructure because it has been outsourced to a
>> malevolent entity?)
> 
> Do mirrors of source, mirrors of issues and email lists solve this
> problem? If so, we don’t plan to shut down that infrastructure. There
> are currently no plans to have GitHub as our only (or main) Git host.

Mailing lists definitely help, because Git works over email.  So, people
without GitHub accounts can submit patches to the mailing list.

(Read-only) mirrors of issues and source seem like sensible things to
have, anyway, for times when the main host is down.  But they obviously
wouldn't let people submit patches or bug reports.

>> # PROBLEMATIC ISSUE NUMBERING AND LINK BREAKAGE
>> 
>> If OpenWRT were, as you said, to "open issues on GitHub.com without
>> any migration of existing issues", then this could lead to broken
>> links in OpenWRT commit messages, bug reports, and comments.
>> 
>> One reason for this is that the issue numbering on GitHub might not
>> remain coordinated with the issue numbering on bugs.openwrt.org .
>> For instance, there might end up being two bug reports with the same
>> number.
>> 
>> That would be like the ambiguity of "#4206", which could currently
>> (sadly, as a result of OpenWRT allowing pull requests on GitHub)
>> refer to either
>>
>> https://bugs.openwrt.org/index.php?do=details&task_id=4206
>> 
>> or
>> 
>> https://github.com/openwrt/openwrt/pull/4206
>> 
>> but worse.
> 
> Yes that’s indeed a _flaw_ when distributing service to different
> entities.

Right.  Allowing bug reports via GitHub is going to create even more
auto-link ambiguity/breakage.

*Migration* of bug reports to SourceHut or Codeberg, on the other hand,
allows existing internal links (within bugs.openwrt.org) to be
straightforwardly transformed into internal links at the chosen host
(e.g. either todo.sr.ht/~openwrt/openwrt or
codeberg.org/openwrt/openwrt/issues ).  That isn't possible with GitHub,
because the existing PRs on OpenWRT's GitHub repo will cause collisions,
as with #4206 above.

> When people refer to flyspray within the commit messages they usually
> prefixed it with `FS`.

Indeed.  Here's an example:
https://github.com/openwrt/openwrt/pull/4981#issuecomment-1018862258

As you can see, the example does not hyperlink to the relevant issue.
So, it's not a very robust solution - and that lack of robustness is
only compounded by GitHub search's false positives bug.

> Sourcehut requires users to post the full address which seems the most
> stable (though least convenient) method[3].
> 
> [3]:
> https://man.sr.ht/git.sr.ht/#referencing-tickets-in-git-commit-messages

I agree with SourceHut: it's worth sacrificing a little short-term
convenience for a big gain in long-term convenience.

> [...] It’s not possible to disable PRs on GitHub and a massive chunk
> of contributions come via the GitHub, I’d estimate more than from the
> mailing list at this point. [...]

This leaves OpenWRT with a headache: how to outsource issue-hosting,
without all those GitHub PRs causing some link-breakage in the process?

As I say, your best option there is probably *migration* of bug reports
to SourceHut or Codeberg, as described a few paragraphs above.

>> [Even] if OpenWRT resists, for now, the *migration* of issues to
>> GitHub, every additional endorsement of GitHub by OpenWRT sadly
>> increases the likelihood that some future OpenWRT dev/maintainer will
>> attempt such a migration in future - probably in ignorance of these
>> problems.
>> 
>> I have seen projects mess up such migrations quite badly, in ways
>> that have knock-on effects for years to come.  For instance
>> TaskWarrior, whose devs/maintainers did not notice that quite a lot
>> of data corruption and link-breakage had occurred during the
>> migration, until it was too late to correct because on GitHub, people
>> had already started to refer to issue numbers that should properly
>> have been reserved for existing issues.
>> 
>> As a result, the many references from one bug report or pull requests
>> to another (e.g. "Fixes #XX" or "See #YY", that sort of thing) and
>> that were silently auto-linked by GitHub to the wrong bug report or
>> pull request, could not longer be fixed without extensive effort
>> (more than could be spared - and so IIUC the issue still persists).
>> See e.g.
>> https://github.com/GothenburgBitFactory/taskwarrior/issues/2088 .
>> 
>> This is a subtle and insidious kind of corruption that GitHub makes
>> it hard to avoid.
> 
> There are no plans to delete all existing tickets created on
> bugs.openwrt.org.

Hm.  As I predicted above, several OpenWRT developers have *already*, in
the last few days, requested migration of those tickets to GitHub.

> Migrating tickets over to GitHub (is possible) could include prefixing
> them with `FS: 123` to make them available via the search function.

As mentioned previously, GitHub's search is buggy and would return false
positives.  That is exactly what happened when TaskWarrior migrated to
GitHub.

> If nobody steps up and offers and maintains (!) a fitting solution we
> have to outsource.

Indeed.  Outsourcing may be a necessary evil.

GitHub or other non-free hosts: an unnecessary evil.

(I do mean "evil".  Even if the other issues reported in this thread
haven't convinced you, please know that GitHub has, from early on,
apparently provided positions of influence to people who put their
wealth, their sexual proclivities, and Microsoft's power, far ahead of
free software.

    "Tom Preston-Werner in his capacity as GitHub’s CEO acted
    inappropriately, including confrontational conduct, disregard of
    workplace complaints, insensitivity to the impact of his spouse’s
    presence in the workplace, and failure to enforce an agreement that
    his spouse should not work in the office.  There were also issues
    surrounding the solicitation of GitHub employees for non-GitHub
    business and the inappropriate handling of employee concerns
    regarding those solicitations."

https://github.blog/2014-04-28-follow-up-to-the-investigation-results/

Also:

http://techrights.org/2021/10/14/github-expose-commences/ 

And this thread, which was originally titled "Balabhadra Graveley –
application for arrest warra... - Hacker News":

https://news.ycombinator.com/item?id=29816098

)

At this point I've raised all my objections about GitHub.  The sole
major objection that I didn't raise - the fact that GitHub is not
accessible to users reliant on IPv6 - has already been raised by others.

Thank you for your engagement with my concerns about GitHub.

Thank you for asking GitHub for a roadmap towards IPv6 adoption.

Thank you for testing and investigating SourceHut and Codeberg.

And thank you for not rushing the process of trying to improve OpenWRT's
infrastructure.

Here's hoping the community chooses a solution that matches OpenWRT's
ethos; that eschews proprietary software, lock-in, and corporate control
over users; and that promotes software freedom, universal accessibility,
and human rights.

Best wishes,

Sam

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.