salsa.debian.org as alternative [Was: Re: Switch issues and CI to GitHub]
Bjørn Mork [2022-01-23 14:26:18]: Hi, > OpenWrt is a rather small project, so it would make sense to piggy-back > on someone with a bit more manpower. salsa.debian.org comes to mind... IIRC it was already proposed in the past already. I'll include following note for future myself: Sun, 27 Feb 2022 "you may have noticed, salsa.debian.org is currently down"[1] Tue, 1 Mar 2022 "over the last days I installed all missing upgrades."[2] Although it's not clear what went wrong, it's probably clear, that managing GL instance isn't pieace of cake even for projects with a bit more manpower. 1. https://lists.debian.org/debian-infrastructure-announce/2022/02/msg0.html 2. https://lists.debian.org/debian-infrastructure-announce/2022/03/msg0.html -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: Switch issues and CI to GitHub
At least for sure it must be two separate sites: one for code hosting and one for downloads. Because it looks like chances to be blocked are higher for the downloads site than for the source hosting. For example VPNs and Tor websites are getting blocked in Russia https://blog.torproject.org/tor-censorship-in-russia/ I think that in many other countries they are already blocked. On Wed, 26 Jan 2022 at 09:01, Sam Kuper wrote: > > On Tue, Jan 25, 2022 at 09:45:52PM +0200, Sergey Ponomarev wrote: > > Well, we may *speculate* and try to minimise risks but that's what I > > tried to say: it's counterproductive. > > Avoiding unnecessary risks is productive. It's one of the ways in which > projects and organisations stay afloat. > > > > > > > At least GH is big enough so that it can protect its users [...] Now > > imagine that OpenWrt or SourceHut or whatewer website will be blocked. > > Who will try to dispute? > > That is a mischaracterisation. > > AFAICT, GitHub is not (in general) blocked *by* Crimea. > > Rather, GitHub itself blocks users *in* Crimea (i.e. connecting from > Crimea) from using *some* GitHub features: > https://docs.github.com/en/github/site-policy/github-and-trade-controls#what-is-available-and-not-available > > GitHub is not "big enough" to protect users *from GitHub itself*, nor > (given that it is headquartered in the USA) *from US Law*. > > > > > But hey, the GH CEO Nat Friedman even, while being a jew, personally > > worked hard to unblock GH in Iran > > https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/ > > Again a mischaracterisation. > > That issue didn't relate to GitHub being blocked *by* Iran. > > Rather, GitHub previously blocked users *in* Iran (i.e. connecting from > Iran) from using some or all GitHub features. > > > (BTW, Nat Friedman isn't GitHub's CEO anymore: > https://www.theregister.com/2021/11/03/github_ceo_quits/ > > Also, I'm not sure he's Jewish, nor why that would be relevant.) > > > > > I just want to say that I personally agree with this concern and still > > for me it looks like GH is at least not a worse option even from this > > point of view. > > Codeberg and SourceHut both seem to be better than GitHub on this front. > > > 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. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Sergey Ponomarev, stokito.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
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/7f7cc0d6934fba7acc211f19a430b49f026e .) 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
Re: Re: Switch issues and CI to GitHub
On Tue, Jan 25, 2022 at 09:45:52PM +0200, Sergey Ponomarev wrote: > Well, we may *speculate* and try to minimise risks but that's what I > tried to say: it's counterproductive. Avoiding unnecessary risks is productive. It's one of the ways in which projects and organisations stay afloat. > At least GH is big enough so that it can protect its users [...] Now > imagine that OpenWrt or SourceHut or whatewer website will be blocked. > Who will try to dispute? That is a mischaracterisation. AFAICT, GitHub is not (in general) blocked *by* Crimea. Rather, GitHub itself blocks users *in* Crimea (i.e. connecting from Crimea) from using *some* GitHub features: https://docs.github.com/en/github/site-policy/github-and-trade-controls#what-is-available-and-not-available GitHub is not "big enough" to protect users *from GitHub itself*, nor (given that it is headquartered in the USA) *from US Law*. > But hey, the GH CEO Nat Friedman even, while being a jew, personally > worked hard to unblock GH in Iran > https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/ Again a mischaracterisation. That issue didn't relate to GitHub being blocked *by* Iran. Rather, GitHub previously blocked users *in* Iran (i.e. connecting from Iran) from using some or all GitHub features. (BTW, Nat Friedman isn't GitHub's CEO anymore: https://www.theregister.com/2021/11/03/github_ceo_quits/ Also, I'm not sure he's Jewish, nor why that would be relevant.) > I just want to say that I personally agree with this concern and still > for me it looks like GH is at least not a worse option even from this > point of view. Codeberg and SourceHut both seem to be better than GitHub on this front. 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: Switch issues and CI to GitHub
Well, we may *speculate* and try to minimise risks but that's what I tried to say: it's counterproductive. For example, did you know that GitHub was blocked in Ukraine for one day? As far as I remember, literally some small court in a village said to block four hundred sites with GH and LiveJournal among them just because there was some gist with links to a cryptocurrency exchange. And Ukrainian laws allow the use of crypto currencies and don't allow anyone to block anything but there was a funny formulation like "seize intellectual property rights that Internet users have when using web resources". That's totally insane and no ISP hadn't blocked anything. That was quickly undone and maybe the judge was punished but still, who might predict this? At least GH is big enough so that it can protect its users and even Ukrainian ministers were worried about this. There was a story when Iranian with Canadian citizenship was blocked in GH when he visited his parents. But hey, the GH CEO Nat Friedman even, while being a jew, personally worked hard to unblock GH in Iran https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/ Now imagine that OpenWrt or SourceHut or whatewer website will be blocked. Who will try to dispute? I'll ask a developer from Crimea if GH is blocked there but I just tried to say that Crimea is a very popular destination unlike North Korea and thouthands of developers are visiting it and not only from Ukraine and Russia. That's a health resort and many astmatic people have to be there periodically because that's the cheapest way for them to survive. The problem here is that you may be blocked *unexpectedly* even before thinking about using VPN. I just want to say that I personally agree with this concern and still for me it looks like GH is at least not a worse option even from this point of view. Also any country which tries to protect its sovereignty, morality or lifestyle from outside influence should limit access from the entire internet itself. And ironically users may need OpenWrt more than others. But I hope that can be simply resolved by mirroring of binaries downloads and local forums. But participating in discussions and contribution still may be a problem but there is not a single good solution for this. At least we know that for core developers and maintainers that's not a problem at all. It's fair to use GH or any other hosting even if it will be accessible only from Germany :) On Tue, 25 Jan 2022 at 20:31, Sam Kuper wrote: > > On Tue, Jan 25, 2022 at 06:56:04PM +0200, Sergey Ponomarev wrote: > > Speaking about GitHub and access to it from sanctioned territories > > this is a really big concern. [..] > > Thank you for corroborating that concern. > > Some news reports, think-tank analysis, and legal guidance providers > suggest the current sanctions will be extended in unspecified ways, if > conflict escalates further in the region. If that happens, I would > *speculate* that for instance GitHub might end up blocking Russia. > > "Washington is trying to maintain transatlantic unity to build a > credible threat of sanctions as a deterrence against Moscow." > > > https://www.theguardian.com/world/2022/jan/25/us-uk-and-europe-totally-united-in-the-face-of-russia-threat-to-ukraine-biden-says > > > "If [Russia] launches a [new] military assault against Ukraine, > Western sanctions should target the Russian economy in a major way. > ... If the Kremlin choses lesser forms of aggression, consider > strong sanctions anyway ... the United States and the European > Union (EU) should use all options at their disposal, including > intensified export controls." > > > https://www.atlanticcouncil.org/blogs/new-atlanticist/what-if-russia-invades-ukraine-again-consider-these-options-for-sanctions-escalation/ > > > "In order to prepare [for possible imminent sanctions, Western] > businesses should do the following: > > - Identify all of their activities which relate to Russia and/or > Russian counterparties and/or Russian origin goods > > - Review (and expand if necessary) existing KYC to identify all > Russian counterparties and their beneficial owners ..." > > > https://www.lexology.com/library/detail.aspx?g=839e7b81-ee92-40bb-87ca-4d9e96eeccb8 > > > > > But let's be honest: that's not only GitHub but any website in the US > > or in NATO countries, > > I may be wrong, but I think some code/issue-hosting sites, including in > the USA or in other NATO jurisdictions, are accessible from sanctioned > territories. > > Potentially, that means SourceHut or CodeBerg would be better solutions > than GitHub in this (and other) respects. Certainly, I could find > nothing in their terms and conditions to indicate that they block users > by territory: > > https://codeberg.org/codeberg/org/src/branch/main/TermsOfUse.md > >
Re: Re: Switch issues and CI to GitHub
On Tue, Jan 25, 2022 at 06:56:04PM +0200, Sergey Ponomarev wrote: > Speaking about GitHub and access to it from sanctioned territories > this is a really big concern. [..] Thank you for corroborating that concern. Some news reports, think-tank analysis, and legal guidance providers suggest the current sanctions will be extended in unspecified ways, if conflict escalates further in the region. If that happens, I would *speculate* that for instance GitHub might end up blocking Russia. "Washington is trying to maintain transatlantic unity to build a credible threat of sanctions as a deterrence against Moscow." https://www.theguardian.com/world/2022/jan/25/us-uk-and-europe-totally-united-in-the-face-of-russia-threat-to-ukraine-biden-says "If [Russia] launches a [new] military assault against Ukraine, Western sanctions should target the Russian economy in a major way. ... If the Kremlin choses lesser forms of aggression, consider strong sanctions anyway ... the United States and the European Union (EU) should use all options at their disposal, including intensified export controls." https://www.atlanticcouncil.org/blogs/new-atlanticist/what-if-russia-invades-ukraine-again-consider-these-options-for-sanctions-escalation/ "In order to prepare [for possible imminent sanctions, Western] businesses should do the following: - Identify all of their activities which relate to Russia and/or Russian counterparties and/or Russian origin goods - Review (and expand if necessary) existing KYC to identify all Russian counterparties and their beneficial owners ..." https://www.lexology.com/library/detail.aspx?g=839e7b81-ee92-40bb-87ca-4d9e96eeccb8 > But let's be honest: that's not only GitHub but any website in the US > or in NATO countries, I may be wrong, but I think some code/issue-hosting sites, including in the USA or in other NATO jurisdictions, are accessible from sanctioned territories. Potentially, that means SourceHut or CodeBerg would be better solutions than GitHub in this (and other) respects. Certainly, I could find nothing in their terms and conditions to indicate that they block users by territory: https://codeberg.org/codeberg/org/src/branch/main/TermsOfUse.md https://codeberg.org/codeberg/org/src/branch/main/PrivacyPolicy.md https://codeberg.org/codeberg/org/src/branch/main/en/bylaws.md https://codeberg.org/codeberg/org/src/branch/main/Imprint.md https://man.sr.ht/terms.md https://man.sr.ht/privacy.md (Basically, IIUC - IANAL - sanctions are intended as deterrents to commercial activities. Non-profit or volunteer activities are less affected. I would *hope* that humanitarian activities - like developing free software that extends the usable life of computer and network infrastructure - would remain unaffected by sanctions, except insofar as commercial US hosts like GitHub might be barred from involvement.) I will write to SourceHut and CodeBerg to ask whether they block users by territory. 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: Switch issues and CI to GitHub
+1 for a GitHub +1 for GitLab +1 for a self hosting GitLab +1 for joining to any existing OS hosting -1 for plain emails. As a contributor but not a core developer I would like to ask. Please tell me honestly. Is the send-patch approach just an IQ test? Because I failed it :) My few patches that I sent are just lost somewhere. Yes, I already know about the patchwork (or how it was called?) but I remember that I missed a NULL check in one place but decided not to send a new update patch just because it's too boring. So if you ever decide to apply the "[PATCH] --header option to pass additional raw HTTP header" please let me know and I'll update it. I tried to contribute on a Weekend and I had only an hour or two while my child was sleeping but I wasted all my time configuring git send-email. I clearly understand that OpenWrt developers mightn't receive many PRs with a poor quality but still this makes many enthusiasts to be involved and increase a trust to the code base. Speaking of which hosting is to choose I really agree with all concerns, even about the LibreJS. And I'm certain that one day we'll have distributed/federated git hostings and comments from one system will be seen by participants in other systems. They are actively developed and this is just a matter of time when they become useful enough. Note that users also need some time to "grow" their skills. For many Junior developers the GitHub is a synonym of Git. At the same time the "centralised" way when many users are already on GitHub even today makes a lot of benefits. We can grow a community and then move to any other place. Speaking about GitHub and access to it from sanctioned territories this is a really big concern. I live in Ukraine but I am going to visit my friend in Crimea for her wedding. And the official GitHub app may detect my location and I'll be blocked even if I as a Ukrainian citizen visited a Ukrainian territory. In my previous work I had two colleagues who often visited their relatives in Crimea. But let's be honest: that's not only GitHub but any website in the US or in NATO countries, and not only in countries that practice blocking like Myanmar. In any country there is potentially a risk of getting blocked. Except for Sealand, maybe only Mongolia and Uruguay don't use blocking until. So even hosting on GitHub may be a "good enough" option. Regards, Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Paul Spooren writes: > None of the OpenWrt project members is willing to setup and maintain a > GitLab instance and there were multiple vetos again gitlab.com. I'll take advantage of not being a member and throw out a crazy question here: Did anyone reach out to other open source projects wrt the possibility of sharing a GitLab instance? OpenWrt is a rather small project, so it would make sense to piggy-back on someone with a bit more manpower. salsa.debian.org comes to mind... They are already pretty open to hosting stuff which isn't Debian: https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa Some parts of OpenWrt, like firmware blobs, probably fail the "can be included in Debian" condition. But I assume it might be possible to discuss special terms for OpenWrt as co-operating project. Worth a try at least? Bjørn (not affiliated with neither OpenWrt nor Debian) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Switch issues and CI to GitHub
> ## Conclusion > > From a FOSS perspective I’d skip GitHub entirely and move to Codeberg or > sr.ht. Codeberg (Gitea) is a fine clone of GitHub and sr.ht comes with a great > _no bloat_ attitude and priority on email integration for tickets and git > (they > created git-send-email.io). Hi, just wanted to repeat what I already said in the virtual meeting so it's documented here as well: I have been using gitea in a different project, mostly by reviewing Pull Requests there. While I started with no particular partiality, and it looked rather well in the beginning, I quickly became annoyed because there is just so much functionality lacking or worse when it is compared to GitHub. From my experience, gitea might be nice for a small project if you absolutely need to host it yourself. But it still does not seem adequate for a mature project, and it's rather improbable that they will be able to keep pace with GitHub and others in the future either. I'm not aware of any particular drawbacks with respect to just hosting Issues there, but that does really not make much more sense than the current solution if it's kept isolated afterwards. From the aspect of pure usability, I'd favor GitHub, as so many other projects do. Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Self hosted GitLab instance [Was: Re: Switch issues and CI to GitHub]
On 22/01/2022 14:37, Petr Štetiar wrote: > Paul Spooren [2022-01-07 10:34:34]: > > Hi, > > (adding openwrt-adm@ into the loop) > >> None of the OpenWrt project members is willing to setup and maintain a >> GitLab instance > so what about having that GitLab instance prepared and co-maintained by some > trusted 3rd party? I mean, define our needs, find someone who would be willing > to do that, estimate the costs and then prepare some fundraiser which should > cover the costs for next 3-5 years, so we don't need to repeat this daunting > task every year. Maintaining the Gitlab instance isn't the only issue. I've seen several people expressing their dislike about Gitlab. I'll list some of my own reasons. * The UI/UX is terribly bloated, making the whole product really cumbersome to work with. * TOTP is required before U2F/FIDO2 hardware keys can be used, and requests to revert that change have been ignored for years. * FIDO2 backed SSH keys are not supported. Reading the issue requesting it is not very confidence inspiring. * Installation instructions "curl ... | sudo bash". Seriously? So pretty please, let us not go the Gitlab route. Github UI/UX, while not being perfect, is way better than Gitlab. And do not mistake this for me advocating Github. I would still prefer to ditch Github and Gitlab entirely, stick to git send-email and patchwork, but it's becoming clear that this is an obstacle for newer generations. Many people seem to use the Gmail web interface, and like it. I find it horrible. I've gotten into a discussion on Twitter about the subject once, and was quickly blamed for excluding people using it. Apparently we are dinosaurs and need to come out of the stone age. Hence I've given up that fight. But if I have to choose between Github and Gitlab, Github wins. Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Self hosted GitLab instance [Was: Re: Switch issues and CI to GitHub]
Paul Spooren [2022-01-07 10:34:34]: Hi, (adding openwrt-adm@ into the loop) > None of the OpenWrt project members is willing to setup and maintain a > GitLab instance so what about having that GitLab instance prepared and co-maintained by some trusted 3rd party? I mean, define our needs, find someone who would be willing to do that, estimate the costs and then prepare some fundraiser which should cover the costs for next 3-5 years, so we don't need to repeat this daunting task every year. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Update buildbots (was: Re: Switch issues and CI to GitHub)
Etienne Champetier [2022-01-20 14:56:28]: Hi, > Any chance you can update the buildbots docker images ? > (I see only you 2 listed as admins here: https://openwrt.org/infrastructure) should be done. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Paul Spooren wrote: >> "Codeberg e.V. is a registered non-profit association based in Berlin, >> Germany" So, this makes me feel better. > I’ll write them an email asking for their long term ideas of > maintaining Gitea. Just because is a “e.V.” and in Germany doesn’t make > it super sustainable, trustworthy or anything. Agreed, but at least it might have a governance model that does not depend upon three guys doing it only their spare time as a lark. (And then getting bored or married or having childen.) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Update buildbots (was: Re: Switch issues and CI to GitHub)
Hi Petr & Jow Le jeu. 20 janv. 2022 à 09:10, Paul Spooren a écrit : > > Hi Etienne, > > >> > >> Currently we’re facing an issue[1] from our heterogeneous buildbot > >> setup[2] that partly uses outdated runners missing packages installed host > >> packages, causing them to upload broken SDKs at random. > > > > My understanding is that buildbot runner are docker containers now so > > we are 1 "docker pull" away from fixing this > > I agree, however someone needs to do that and also do it in the future. Any chance you can update the buildbots docker images ? (I see only you 2 listed as admins here: https://openwrt.org/infrastructure) Best Etienne > We could also automate it[1], but from what I remember people didn’t like the > idea. > > [1]: https://github.com/containrrr/watchtower > > Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Hi Etienne, >> >> Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2] >> that partly uses outdated runners missing packages installed host packages, >> causing them to upload broken SDKs at random. > > My understanding is that buildbot runner are docker containers now so > we are 1 "docker pull" away from fixing this I agree, however someone needs to do that and also do it in the future. We could also automate it[1], but from what I remember people didn’t like the idea. [1]: https://github.com/containrrr/watchtower Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Hi Paul, Le jeu. 20 janv. 2022 à 05:04, Paul Spooren a écrit : > > Hi Florian, > > > I have now been persuaded to share my thoughts on the subject as well. > > Thank you. > > > Why not gitlab? > > Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them. > > Some people don’t like the particularly “bloated” interface of GitLab but I > agree, they offer the stuff we’re looking for (and much much much more we > don’t). > > > And if necessary, we can also host everything ourselves. > > That’s not an entirely new idea. However in the last three years nobody > stepped up to host (and maintain) it. Setting up a GitLab instance is easy > enough, hosting it for the next 15 years or something is a bit more of a > task. None of the OpenWrt project members were particularly excited about > hosting it. > > > > > What I like is the CI handling with the gitlabrunners. > > We can take the ones from Gitlab or we can configure gitlabrunners running > > on our own hardware. > > When you say GitLab here I’m assuming GitLab.com. During the vote multiple > people were against GitLab.com due to their past in buying and shutting down > another Git service. It’s surely possible to host GitLab and a bunch of > workers ourselves, the question is, do we want that? > > Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2] > that partly uses outdated runners missing packages installed host packages, > causing them to upload broken SDKs at random. My understanding is that buildbot runner are docker containers now so we are 1 "docker pull" away from fixing this Best Etienne > > Somewhere in the thread @arprcar I read that gitlab is not an option. > > Unfortunately, it didn't say why. > > Did you mean hosting it yourself? > > Neither GitLab.com nor a self hosted GitLab instance seem great at this point. > > [1]: https://github.com/openwrt/packages/pull/17645#issuecomment-1016548435 > [2]: https://buildbot.openwrt.org/master/images/#/workers > > Best, > Paul > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Hi Florian, > I have now been persuaded to share my thoughts on the subject as well. Thank you. > Why not gitlab? > Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them. Some people don’t like the particularly “bloated” interface of GitLab but I agree, they offer the stuff we’re looking for (and much much much more we don’t). > And if necessary, we can also host everything ourselves. That’s not an entirely new idea. However in the last three years nobody stepped up to host (and maintain) it. Setting up a GitLab instance is easy enough, hosting it for the next 15 years or something is a bit more of a task. None of the OpenWrt project members were particularly excited about hosting it. > > What I like is the CI handling with the gitlabrunners. > We can take the ones from Gitlab or we can configure gitlabrunners running on > our own hardware. When you say GitLab here I’m assuming GitLab.com. During the vote multiple people were against GitLab.com due to their past in buying and shutting down another Git service. It’s surely possible to host GitLab and a bunch of workers ourselves, the question is, do we want that? Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2] that partly uses outdated runners missing packages installed host packages, causing them to upload broken SDKs at random. > Somewhere in the thread @arprcar I read that gitlab is not an option. > Unfortunately, it didn't say why. > Did you mean hosting it yourself? Neither GitLab.com nor a self hosted GitLab instance seem great at this point. [1]: https://github.com/openwrt/packages/pull/17645#issuecomment-1016548435 [2]: https://buildbot.openwrt.org/master/images/#/workers Best, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Hi Michael, > "Codeberg e.V. is a registered non-profit association based in Berlin, > Germany" > So, this makes me feel better. I’ll write them an email asking for their long term ideas of maintaining Gitea. Just because is a “e.V.” and in Germany doesn’t make it super sustainable, trustworthy or anything. Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Hi Sam,
>
> A big thank you for doing this.
Half the fun.
>
> Must confess: I was unaware of the ~16k issue body character limit when
> I proposed SourceHut. Did you find a public bug report or feature
> request about that? (I looked just now. Could not find one myself, but
> perhaps my search-fu is off today.)
I discussed this with Drew (sourcehut developer) and the limit is due to email
compatibility.
>
>> A quick bug tracker conclusion, I'd be happy to use codeberg.org for
>> issue tracking. Both sr.ht and codeberg.org are FOSS, GitHub not so
>> much. [..]
>
> GitHub not at all, last time I checked.
Some of their frameworks, actions etc are open source, however their core
isn’t, right.
>
>> As an immediate action, we might as well close down bugs.openwrt.org
>> and open issues on GitHub.com without any migration of existing
>> issues. Both users and developers already know the workflows over
>> there and issues have a higher visibility. A migration away from
>> GitHub over to coderberg or sr.ht is possible with much less effort
>> than migrating away from flyspray.
>
> I wish to caution against this.
>
> Here are some reasons not to use GitHub for hosting issue/bug-reports.
>
>
> # BROKEN HANDLING OF USER ACCOUNT DELETIONS
>
> Best practice for handling user account deletions is to either:
>
> 1. If the user is happy for a record of their contributions to remain
>attributed to them:
>
>Leave the username shown unchanged in the remaining webpages where
>it was used, so that at-mentions ("@username") within discussions
>still work (aren't broken), and quotations remain correctly
>attributed ("username commented MMM DD, ").
>
>Or...
>
> 2. If the user is *not* happy for that:
>
>Replace all instances of the username (at-mentions, quotation
>attributions, etc) with a non-personally-identifying pseudonym, e.g.
>"user12345".
>
>This, too, retains comprehensibility and avoids link-breakage.
>
>
> GitHub does neither.
>
> Instead, GitHub replaces *some but not all* instances of a deleted
> user's username with "Ghost". That can make it difficult to follow a
> discussion (bug report, pull request, etc) featuring a now-deleted user.
>
> See e.g. https://github.com/GothenburgBitFactory/taskwarrior/issues/2088
> . If you didn't know that the comments therein that are now attributed
> to "Ghost" were in fact made by me, it would be a confusing discussion
> to follow.
>
> (I later closed my GitHub account due to the increasing accessibility
> problems I encountered on GitHub.)
>
> That would be bad enough. But because *every* deleted user account is
> processed this way by GitHub, it effectively conflates *all* deleted
> users into one confusing account. For instance, the "Ghost" account
> here is *not* me: https://github.com/matrix-org/synapse/issues/5778 .
> But a third party would be unable to know that.
>
>
>
> This is especially problematic if more than one now-deleted user
> contributed to a single discussion. Both user's posts would now be
> attributed - by GitHub's incompetence - to the same user, making it look
> as though one, rather than several, people made those comments. (I
> don't have an example at hand, but I'd be amazed if this hasn't happened
> several times now, given GitHub's size.)
I think they are in a bit of a pickle there. If you delete everything a lot of
issues miss comments and stop making sense. 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. Their solution seems to combine “anonymity" with usability (aka not
ruining issue discussions entirely).
>
>
> 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
[1]: https://github.com/github/feedback/discussions
>
> # BROKEN SEARCH
>
> There is no way within GitHub to avoid irrelevant search results. For
> instance, if I search in the TaskWarrior repo for
>
>is:issue in:title "TW-10"
>
> I get results like "[TW-1733] taskwarrior 2.5.0 can not compile FreeBSD
> 10.1", because they have a "TW" and a "10" in the title. In other
> words, GitHub fails to perform exact string matching.
>
> Try it yourself:
> https://github.com/GothenburgBitFactory/taskwarrior/issues?utf8=%E2%9C%93=is%3Aissue+in%3Atitle+%22TW-10%22
>
> This makes GitHub's search feature a real pain to use.
>
> Again, because GitHub is proprietary and lacks good ways to track or fix
> GitHub bugs, ones like this go unfixed for years.
This critique came up multiple times, are you aware of a better search
implementation? I’d be keen to find something
Re: Switch issues and CI to GitHub
I have now been persuaded to share my thoughts on the subject as well. Since this is a major change. In itself, I think it is good that thought is being given to unification. Github was the first web-based source code management tool. So I think it's just that most of user are also on github. However, since Microsoft has joined the game, I am in worry about the transparency. Yes, Mircosoft has improved in that aspect. But it always depends on the company philosophy if they love or hate FOSS :-) Why not gitlab? Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them. And if necessary, we can also host everything ourselves. What I like is the CI handling with the gitlabrunners. We can take the ones from Gitlab or we can configure gitlabrunners running on our own hardware. Somewhere in the thread @arprcar I read that gitlab is not an option. Unfortunately, it didn't say why. Did you mean hosting it yourself? Best Regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Thank you for this great report! I did not know codeberg existed, but when I looked, discovered I already had a login! I would go with codeberg. It's okay that many community repos are on git, git makes cloning easy. Who is funding codeberg, and how stable is that funding? "Codeberg is not a corporation" <- maybe they mean "not a VC sponsored for-profit corporation" Because even Greenpeace is incorporated, and therefore has a clear governance model, and set of bylaws. "Codeberg e.V. is a registered non-profit association based in Berlin, Germany" So, this makes me feel better. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Tue, Jan 18, 2022 at 03:38:43PM +0100, Paul Spooren wrote:
> ## Bug Tracker
>
> I looked today into migrating issues from bugs.openwrt.org over to
> GitHub.com, codeberg.org (GiTea) and todo.sr.ht (Sourcehut). [..]
>
> While sr.ht allows to import the large collection of issues, each
> message is limited to about 16.000 characters which would require us
> to truncate existing tasks and comments (and instead have them on some
> paste service). This limit is likely tied to the first class email
> support, users without an account can write to a special email address
> and create tickets without registering at all. Try it by sending
> something to ~aparcar/openwrt-bugs-import-tes...@todo.sr.ht
>
> [..] If we decide to move there, tools like gh2srht[3] would allow a
> quick migration. To get a feel what the bug tracker over at sr.ht
> would look like I migrated as much as possible, feel free to have a
> look[4].
A big thank you for doing this.
Must confess: I was unaware of the ~16k issue body character limit when
I proposed SourceHut. Did you find a public bug report or feature
request about that? (I looked just now. Could not find one myself, but
perhaps my search-fu is off today.)
If not, I will aim to post one, referencing this discussion thread.
Thanks again,
Sam
> A quick bug tracker conclusion, I'd be happy to use codeberg.org for
> issue tracking. Both sr.ht and codeberg.org are FOSS, GitHub not so
> much. [..]
GitHub not at all, last time I checked.
> As an immediate action, we might as well close down bugs.openwrt.org
> and open issues on GitHub.com without any migration of existing
> issues. Both users and developers already know the workflows over
> there and issues have a higher visibility. A migration away from
> GitHub over to coderberg or sr.ht is possible with much less effort
> than migrating away from flyspray.
I wish to caution against this.
Here are some reasons not to use GitHub for hosting issue/bug-reports.
# BROKEN HANDLING OF USER ACCOUNT DELETIONS
Best practice for handling user account deletions is to either:
1. If the user is happy for a record of their contributions to remain
attributed to them:
Leave the username shown unchanged in the remaining webpages where
it was used, so that at-mentions ("@username") within discussions
still work (aren't broken), and quotations remain correctly
attributed ("username commented MMM DD, ").
Or...
2. If the user is *not* happy for that:
Replace all instances of the username (at-mentions, quotation
attributions, etc) with a non-personally-identifying pseudonym, e.g.
"user12345".
This, too, retains comprehensibility and avoids link-breakage.
GitHub does neither.
Instead, GitHub replaces *some but not all* instances of a deleted
user's username with "Ghost". That can make it difficult to follow a
discussion (bug report, pull request, etc) featuring a now-deleted user.
See e.g. https://github.com/GothenburgBitFactory/taskwarrior/issues/2088
. If you didn't know that the comments therein that are now attributed
to "Ghost" were in fact made by me, it would be a confusing discussion
to follow.
(I later closed my GitHub account due to the increasing accessibility
problems I encountered on GitHub.)
That would be bad enough. But because *every* deleted user account is
processed this way by GitHub, it effectively conflates *all* deleted
users into one confusing account. For instance, the "Ghost" account
here is *not* me: https://github.com/matrix-org/synapse/issues/5778 .
But a third party would be unable to know that.
This is especially problematic if more than one now-deleted user
contributed to a single discussion. Both user's posts would now be
attributed - by GitHub's incompetence - to the same user, making it look
as though one, rather than several, people made those comments. (I
don't have an example at hand, but I'd be amazed if this hasn't happened
several times now, given GitHub's size.)
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.
# BROKEN SEARCH
There is no way within GitHub to avoid irrelevant search results. For
instance, if I search in the TaskWarrior repo for
is:issue in:title "TW-10"
I get results like "[TW-1733] taskwarrior 2.5.0 can not compile FreeBSD
10.1", because they have a "TW" and a "10" in the title. In other
words, GitHub fails to perform exact string matching.
Try it yourself:
https://github.com/GothenburgBitFactory/taskwarrior/issues?utf8=%E2%9C%93=is%3Aissue+in%3Atitle+%22TW-10%22
This makes GitHub's search feature a real pain to use.
Again, because GitHub is proprietary and lacks good ways to track or fix
GitHub bugs, ones like this go unfixed for years.
# ACCESSIBILITY, PRIVACY, AND ETHICS PROBLEMS
As
Re: Switch issues and CI to GitHub
Hi all, Thanks for the active discussion. My thoughts on the three topics bug tracker, CI and Git _root_. ## Bug Tracker I looked today into migrating issues from bugs.openwrt.org over to GitHub.com, codeberg.org (GiTea) and todo.sr.ht (Sourcehut). The migration path is somewhat easy extending the fly-build-csv[1] to export tickets and comments from a Flyspray SQL dump. The resulting tasks.csv and comments.csv can be exported to the bug tracker of choice. While sr.ht allows to import the large collection of issues, each message is limited to about 16.000 characters which would require us to truncate existing tasks and comments (and instead have them on some paste service). This limit is likely tied to the first class email support, users without an account can write to a special email address and create tickets without registering at all. Try it by sending something to ~aparcar/openwrt-bugs-import-tes...@todo.sr.ht Apart from that there (might be) are minor bugs which is totally understandable since sr.ht is still considered Alpha[2]. I’d prefer to give it more time before considering moving over there. If we decide to move there, tools like gh2srht[3] would allow a quick migration. To get a feel what the bug tracker over at sr.ht would look like I migrated as much as possible, feel free to have a look[4]. Migrating existing issues to GitHub seems unfeasible, while it’s technically possible[5] their rate limits prevent me (or a bot account) to effectively transport open issues and comments. In case we choose GitHub, a static version of bugs.openwrt.org should stay online. Lastly I looked at codeberg.org which runs Gitea(.com) under the hood. From my understanding it’s a German _registered association_ (eingetragener Verein) with the goal to provide code hosting - great. Their API is well documented[5] and in no time at all I migrated some 4000 issues including comments[6]. It looks and feels like GitHub with some extra buttons, like you can assign issues to specific branches! A quick bug tracker conclusion, I’d be happy to use codeberg.org for issue tracking. Both sr.ht and codeberg.org are FOSS, GitHub not so much. It's possible to migrate all existing issues to codeberg and turn off bugs.openwrt.org entirely, no need to host a static copy. They also allow to login via GitLab.com and GitHub.com accounts lowering the bar for user to participate. If this seems a feasible option I’d rework the migration script and create them with a bot account, including username and time/date in the issues. As an immediate action, we might as well close down bugs.openwrt.org and open issues on GitHub.com without any migration of existing issues. Both users and developers already know the workflows over there and issues have a higher visibility. A migration away from GitHub over to coderberg or sr.ht is possible with much less effort than migrating away from flyspray. ## CI Codeberg does not offer any CI at all except an integration for a self hosted Drone CI setup[7]. That setup would keep the burden of server maintenance on our side, which makes it unfeasible. On the other hand sr.ht offers excellent CI in many flavors[8] (except macOS) which even allows to login on runners to manually debug failed runs. On all machines it’s possible to install Docker and run our own containers or trust in the package stability of Debian et al. I tested it in the past and it works great[9]. GitHub offers free CI which is already heavily used from our side. The package.git repository ran about 11.000 times since I added it in September 2020. They offer up to 40 parallel running jobs which could even take over snapshot building (about 2 hours per target). A quick CI conclusion, I’d start using GitHub CI for openwrt.git since we’re burning plenty of CPU and I don’t want to annoy sr.ht users and maintainers by flooding their infrastructure. In practice that would mean we have a folder called .github/ in our repository. However, we could also use some of the donated money and donate it ourselves to sr.ht hoping they invest in more CI runners. ## Git _root_ We’re currently maintaining multiple servers to host our many Git repositories (GitHub is just a mirror). Instead we could move to one of the three services and use them as our Git _root_. From what I know sr.ht does not offer any organization accounts for now, we’d have to use a shared one until it’s implemented. Codeberg and GitHub do support organizations. Sourcehut devs are the only ones thinking about supporting pre-commit hooks to allow "Signed-of-by” checks and more, something we have on git.openwrt.org. A workaround for Codeberg and Github is to disable direct pushes and only ever allow merging of PRs, which is a bit of a sad workflow downgrade. All three of them support 2FA, Codeberg support U2F and soon FIDO2[10], GitHub support FIDO2. All three play fine with in issue references in commit messages,
Re: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Op 9 jan. 2022, om 19:16 heeft Arne Zachlod het volgende geschreven: > > On 1/7/22 10:34, Paul Spooren wrote: >> Hi all, >> Back at the Hamburg meeting in 2019 and a succeeding vote we decided to >> migrate over to a self-hosted GitLab instance. Some years passed and nothing >> really happened so I’d like to give this another go. >> None of the OpenWrt project members is willing to setup and maintain a >> GitLab instance and there were multiple vetos again gitlab.com. > > Hi, > > I just wanted to ask what the concerns against gitlab.com were in this > meeting, and if they still apply now, more than 2 years later? > Maybe it would be a good compromise to go to gitlab instead of github, > because that way we keep the option to migrate to a self hosted instance in > case something goes wrong? > > Arne > LWN has noticeably written about the uncomfortable feelings associated with depending on non-free services: see https://lwn.net/Articles/879697/ sub "Use of centralized, proprietary services will be a bone of contention in 2022" Paul --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Op 9 jan. 2022, om 19:16 heeft Arne Zachlod het volgende geschreven: > > On 1/7/22 10:34, Paul Spooren wrote: >> Hi all, >> Back at the Hamburg meeting in 2019 and a succeeding vote we decided to >> migrate over to a self-hosted GitLab instance. Some years passed and nothing >> really happened so I’d like to give this another go. >> None of the OpenWrt project members is willing to setup and maintain a >> GitLab instance and there were multiple vetos again gitlab.com. > > Hi, > > I just wanted to ask what the concerns against gitlab.com were in this > meeting, and if they still apply now, more than 2 years later? > Maybe it would be a good compromise to go to gitlab instead of github, > because that way we keep the option to migrate to a self hosted instance in > case something goes wrong? > > Arne > LWN has noticeably written about the uncomfortable feelings associated with depending on non-free services: see https://lwn.net/Articles/879697/ sub "Use of centralized, proprietary services will be a bone of contention in 2022" Paul --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On 1/7/22 10:34, Paul Spooren wrote: Hi all, Back at the Hamburg meeting in 2019 and a succeeding vote we decided to migrate over to a self-hosted GitLab instance. Some years passed and nothing really happened so I’d like to give this another go. None of the OpenWrt project members is willing to setup and maintain a GitLab instance and there were multiple vetos again gitlab.com. Hi, I just wanted to ask what the concerns against gitlab.com were in this meeting, and if they still apply now, more than 2 years later? Maybe it would be a good compromise to go to gitlab instead of github, because that way we keep the option to migrate to a self hosted instance in case something goes wrong? Arne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Hi Hauke, On 1/9/22 17:55, Hauke Mehrtens wrote: The criteria from gnu.org are irrelevant to me and I agree with Rosen and Bjørn on that topic. I would prefer a vote like this, this is just an example not the official vote: - Migrate bug reporting from bugs.openwrt.org to github. Make bugs.openwrt.org read only like dev.openwrt.org. Do not migrate the bug reports, people can create new bugs on github, like copy the content to manually. Do you agree to this plan? Yes No - In addition to that: There is (at least in my opinion) no downside to using GitHub actions as an additional CI for PRs (Think of SoB, checkpatch). This would reduce feedback cycles while being not controversial (packages uses the same model, nobody loses anything over that). Best David Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On 1/7/22 10:34, Paul Spooren wrote: Hi all, Back at the Hamburg meeting in 2019 and a succeeding vote we decided to migrate over to a self-hosted GitLab instance. Some years passed and nothing really happened so I’d like to give this another go. None of the OpenWrt project members is willing to setup and maintain a GitLab instance and there were multiple vetos again gitlab.com. Our current bug tracker at bugs.openwrt.org is used by a minority of users (and devs), all community repositories (LuCI, packages, …) use GitHub for issue tracking. Instead of maintaining flyspray and the server, I’d like to export all flyspray issues, migrate them to GitHub and open GitHub issues for openwrt/openwrt to the public. A static or read-only version of flyspray could be hosted for the near future. Secondly I’d like to give the CI of the main repository another go. Our CI to build Docker images is currently on gitlab.com, I’d migrate that over to GitHub. Also I’d suggest to add similar CI checks as added to the packages (and routing and video and LuCI) repository. We could compile targets and tooling, check checksums etc, even build snapshots to lower the resource usage of our Buildbot infrastructure. During a recent _poll_ in #openwrt-adm multiple members liked the idea, however before doing or voting on anything, I’d like to ask for more comments. Thanks for all feedback, Paul Hi, I like the idea to migrate to github. I think there are multiple aspects. 1) Migrate bugs.openwrt.org to github. 2) migrate the main source repository to github 3) Use the github CI. I would prefer if we use all of this from github in the future, but lets start with bugs.openwrt.org first. Pros for bugs.openwrt.org on github: 1. It is a cloud server we do not have to maintain 2. It is free, we do not have to pay for it, beg for money or sponsoring 3. It allows nice liking between issues, pull requests and commits 4. A lot of our community is already there and used to it. 5. It supports some automation. Cons for bugs.openwrt.org on github 1. It is run by MS. I do not think we would have to pay for the basic features in the future, MS wants to make money from their big cooperate customers. 2. US export laws. Access from North Korea, Crimea and Syria to github is blocked, Cuba and Iran have some sort of exception. Probably no one will care if we ignore such laws on openwrt.org. 3. Users have to create a account at github / MS. It is possible to export the issues on github. I am not really worried about government take downs, as we do not do much which insults government leaders like content about Winnie the Pooh. DMCA or GDPR take downs are probably much more likely for us. If we use a small service hosted by someone else we are also more or less depended on them if they want to continue this service and user also need an account there. We should reduce the services we maintain our self, we also need people doing the actual maintenance work. The criteria from gnu.org are irrelevant to me and I agree with Rosen and Bjørn on that topic. I would prefer a vote like this, this is just an example not the official vote: - Migrate bug reporting from bugs.openwrt.org to github. Make bugs.openwrt.org read only like dev.openwrt.org. Do not migrate the bug reports, people can create new bugs on github, like copy the content to manually. Do you agree to this plan? Yes No - Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
>> You must be >> a) human, >> b) age 13 or older, and >> c) obey US law. >> >> So who exactly can have a SourceHut account but not a Github account? >At least anyone who: >- doesn't run proprietary JavaScript; or >- boycotts PRISM participants (e.g. Microsoft); or >- boycotts GitHub or Microsoft for other reasons; or >- accesses via Tor (IIRC - some time ago now). >Also, people in the following territories have limited or no GitHub >access: >- Syria >- Crimea >- North Korea. >People in those territories potentially have far more need of >trustworthy routers, whose code is under their own control, than people >almost anywhere else in the world. While I personally hope those countries can access github freely, it's not something Openwrt can resolve, maybe you can fork Openwrt somewhere else and design a way for them to access? a project is not United Nation counsel that _will_ solve world peace issues, it just can't. The reality is openwrt can barely make one release a year, whatever infrastructure can help the project benefits us all. Others are free to help those countries to access openwrt(which is why TOR exists, for example), but let's not burden the core team with political responsibility, and let openwrt keep making the best OSS software possible. Shaw ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Sat, Jan 08, 2022 at 08:02:30PM +0100, Bjørn Mork wrote: > Sam Kuper writes: >> Not everyone has, or can have, a Microsoft (GitHub) account. > > Please explain. > > These terms are pretty much identical: > > > https://docs.github.com/en/github/site-policy/github-terms-of-service#b-account-terms > https://man.sr.ht/terms.md#account-terms > > You must be > a) human, > b) age 13 or older, and > c) obey US law. > > So who exactly can have a SourceHut account but not a Github account? At least anyone who: - doesn't run proprietary JavaScript; or - boycotts PRISM participants (e.g. Microsoft); or - boycotts GitHub or Microsoft for other reasons; or - accesses via Tor (IIRC - some time ago now). Also, people in the following territories have limited or no GitHub access: - Syria - Crimea - North Korea. People in those territories potentially have far more need of trustworthy routers, whose code is under their own control, than people almost anywhere else in the world. Developers there perhaps also need more than most to have chances to improve their skills, so as to build/maintain local infrastructure or to emigrate to an employer in a more hospitable country. 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Sam Kuper writes: > Not everyone has, or can have, a Microsoft (GitHub) account. Please explain. These terms are pretty much identical: https://docs.github.com/en/github/site-policy/github-terms-of-service#b-account-terms https://man.sr.ht/terms.md#account-terms You must be a) human, b) age 13 or older, and c) obey US law. So who exactly can have a SourceHut account but not a Github account? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Sat, Jan 08, 2022 at 10:31:01AM -0600, Lao Shaw wrote: > github is used by so many open source projects and it becomes the de > facto git repo platform for many, This is a tragedy. > what makes openwrt so special to the point that github is not good > enough and your idea will do better (for long term with reliability > and easy to maintain)? what exactly is that and why all those OSS > projects are fine with it. This is majoritarian thinking. It's like architects neglecting, for centuries, to include step-free access in public buildings, because "Most people are OK with it." It excludes others. Not everyone has, or can have, a Microsoft (GitHub) account. Not everyone uses proprietary JavaScript or is otherwise able to report bugs or submit patches GitHub. > Move the CI and repos and issues and even discussions to github No, please DO NOT move OpenWRT core infrastructure to GitHub. > so the resource-limited core developers can focus on evolving openwrt > itself, instead of spending cycles on its infrastructure. If OpenWRT devs/maintainers want to outsource code/bug-hosting, please look at accessible FOSS hosts like SourceHut, as previously mentioned. Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
> > Hi all, > > Back at the Hamburg meeting in 2019 and a succeeding vote we decided to > migrate over to a self-hosted GitLab instance. Some years passed and nothing > really happened so I’d like to give this another go. > > None of the OpenWrt project members is willing to setup and maintain a GitLab > instance and there were multiple vetos again gitlab.com. > > Our current bug tracker at bugs.openwrt.org is used by a minority of users > (and devs), all community repositories (LuCI, packages, …) use GitHub for > issue tracking. Instead of maintaining flyspray and the server, I’d like to > export all flyspray issues, migrate them to GitHub and open GitHub issues for > openwrt/openwrt to the public. A static or read-only version of flyspray > could be hosted for the near future. > > Secondly I’d like to give the CI of the main repository another go. Our CI to > build Docker images is currently on gitlab.com, I’d migrate that over to > GitHub. Also I’d suggest to add similar CI checks as added to the packages > (and routing and video and LuCI) repository. We could compile targets and > tooling, check checksums etc, even build snapshots to lower the resource > usage of our Buildbot infrastructure. > > During a recent _poll_ in #openwrt-adm multiple members liked the idea, > however before doing or voting on anything, I’d like to ask for more comments. > > Thanks for all feedback, > Paul +1 for github. The complain about ethical gnu stuff seems a bit wrong and IMHO doesn't really makes sense. The only complaint about github is that it has some limitations for CI and that it is run by ""evil"" MS. Aside from that if used correctly Github is very powerful. Just check some project like vscode or terminal where you can set bot to quickly handle wrongly formatted issues or pr. (I notice we have many) Currently the system for reporting bug is problematic and most of the time users don't even know it's a thing. Also the priority and the tracking system is a bit wrong. On top of that, moving importance to github would also makes devs care more about pr on Github instead of only checking the mailing list. Using the mailing list is good for devs that mainly focus on kernel and stuff but it's a nightmare for WIP or very big project like kernel transition or platform change. Another good tools that would benefit openwrt by using github is all the project system or also the basic milestone thing. Would be good to start creating an Issue that would summarize the target for a specific release. That would massively increase the tracking of it and make it clear where to focus. In short, my idea is to try in every way possible to unify stuff and start using more tools/feature to make it clear the current development state. There was a proposal of dropping the opkg upgrade stuff and move to a "quicker" release phase (aka publish more version). It's a little OT but I still think it's related to this kind of change. Using the project/milestone feature would remove all the hassle of creating a changelog/wiki entry/forum post for free as these minor releases will be on github with a linked issue/milestone. One small complaint I have is that I notice in the last few months a bit of confusion of the main target for the next release. We have the wiki page but we have no way to check the status. Example: - fw4 transition, we have a github issue but we were in a limbo for at least a month and current situation is to set it by default to force packages dev to update their package - 5.10 transition, email on mailing list and issue on a dev github page that got lost - dsa transition, many wip pr no tracking - ujail no idea but massive work under the hood by some packages? I'm an active openwrt user and many times I find some difficulties tracking the development state. Most of the time I check the git page and watch feature magically appear but it would be good to have a better tracking system and know what is the current direction of the team. In short, I'm very positive about a github migration but I really advise to put some effort and make it the right way by giving user/external devs more info about the current development state. (and also introduce some bots to autoclose/auto alert user of bad pr/issue to prevent any junk) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Rosen Penev writes: > https://www.gnu.org/software/repo-criteria-evaluation.html seems to be > complete garbage. Seems the higher the criteria, the less users. Yes, I encourage everyone to read that page. Personally, it made me worry more about the FSFs definition of freedom than using github... IMHO, upholding the laws of the national state you operate in is good. We all know by now that is is possible to define a state as "good", "bad" or "evil". But regardless of how you categorize the US, I think it would be far worse if Github didn't obey US law by complying with current US sanctions. Requiring non-free javascript for browser access. OK, valid point. But really? That battle was lost 20 years ago. Don't use a browser if you dislike non-free javascript. Couldn't even find librejs or icecat in Debian, but that might just be me? Github tries to be transparent about government takedowns, publishing as much as they can on https://github.com/github/gov-takedowns . This seems to be used as an argument against github? Where do I find the complete list of government takedonws affecting savannah.gnu.org projects? There is none? Well, THAT worries me. A lot. And then we have the big licensing argument. As a GPL project, why should you care whether the hosting site forces other hosted projects to use GPL (or other free) licensing? Which sites deserves the "libre" label: The site allowing any license, or the site allowing only FSF approved licenses? Looks like the FSF "freedom" is pretty limited to me. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Fri, Jan 7, 2022 at 1:38 AM Paul Spooren wrote: > > Hi all, > > Back at the Hamburg meeting in 2019 and a succeeding vote we decided to > migrate over to a self-hosted GitLab instance. Some years passed and nothing > really happened so I’d like to give this another go. > > None of the OpenWrt project members is willing to setup and maintain a GitLab > instance and there were multiple vetos again gitlab.com. > > Our current bug tracker at bugs.openwrt.org is used by a minority of users > (and devs), all community repositories (LuCI, packages, …) use GitHub for > issue tracking. Instead of maintaining flyspray and the server, I’d like to > export all flyspray issues, migrate them to GitHub and open GitHub issues for > openwrt/openwrt to the public. A static or read-only version of flyspray > could be hosted for the near future. > > Secondly I’d like to give the CI of the main repository another go. Our CI to > build Docker images is currently on gitlab.com, I’d migrate that over to > GitHub. Also I’d suggest to add similar CI checks as added to the packages > (and routing and video and LuCI) repository. We could compile targets and > tooling, check checksums etc, even build snapshots to lower the resource > usage of our Buildbot infrastructure. > > During a recent _poll_ in #openwrt-adm multiple members liked the idea, > however before doing or voting on anything, I’d like to ask for more comments. +1 for github. https://www.gnu.org/software/repo-criteria-evaluation.html seems to be complete garbage. Seems the higher the criteria, the less users. > > Thanks for all feedback, > Paul > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Indeed, so +1 Paul > Op 7 jan. 2022, om 13:07 heeft Sam Kuper het > volgende geschreven: > > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: >> Instead of maintaining flyspray and the server, I’d like to export all >> flyspray issues, migrate them to GitHub and open GitHub issues for >> openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). > > Thanks, > > Sam > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Indeed, so +1 Paul > Op 7 jan. 2022, om 13:07 heeft Sam Kuper het > volgende geschreven: > > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: >> Instead of maintaining flyspray and the server, I’d like to export all >> flyspray issues, migrate them to GitHub and open GitHub issues for >> openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). > > Thanks, > > Sam > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 07/01/2022 12:07, Sam Kuper wrote: On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: Instead of maintaining flyspray and the server, I’d like to export all flyspray issues, migrate them to GitHub and open GitHub issues for openwrt/openwrt to the public. Please don't do this. GitHub has substantial accessibility and privacy flaws, compared to other options - and fails ethical code/bug-hosting criteria: https://www.gnu.org/software/repo-criteria-evaluation.html Please either stick with existing arrangements, or go with an ethical, accessible code/bug-host (e.g. SourceHut https://sr.ht ). Thanks, Sam Hi Github is better for people using screen readers than flyspray. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Fri, Jan 07, 2022 at 12:07:38PM +, Sam Kuper wrote: > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: > > Instead of maintaining flyspray and the server, I’d like to export all > > flyspray issues, migrate them to GitHub and open GitHub issues for > > openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). +1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: > Instead of maintaining flyspray and the server, I’d like to export all > flyspray issues, migrate them to GitHub and open GitHub issues for > openwrt/openwrt to the public. Please don't do this. GitHub has substantial accessibility and privacy flaws, compared to other options - and fails ethical code/bug-hosting criteria: https://www.gnu.org/software/repo-criteria-evaluation.html Please either stick with existing arrangements, or go with an ethical, accessible code/bug-host (e.g. SourceHut https://sr.ht ). Thanks, Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
