Re: Scaling issues with forges Was: Trying out Codeberg

Hi, On Tue, 11 Mar 2025 at 13:12, Suhail Singh wrote: > Are the relevent portions of your .emacs or init.el accessible > somewhere? https://gitlab.com/zimoun/my-conf Cheers, simon

Re: Trying out Codeberg

Hi, On Thu, 13 Mar 2025 at 10:36, Adrien 'neox' Bourmault wrote: > the default CI recipes/code depends on > docker.io images Well, Cuirass (one CI tool used by the Guix project) is able to work with Forgejo. > nodeJS and npm. Also, the javascript

Re: Trying out Codeberg

Hello, Adrien 'neox' Bourmault writes: [...] > If I can help by sharing Libre en Communs' experience, I'll be very > happy to do so. I'll start here by explaining a bit what I have in > mind. > > Libre en Communs needed a forge software to be able to provide means > for people (both very techni

Re: Scaling issues with forges Was: Trying out Codeberg

On Sun, 9 Mar 2025 17:26:07 -0400 Leo Famulari wrote: > And only using GPL2 is part of that. It's a pragmatic choice in favor > of the goals of Linux's leadership team, which are different from > GNU's goals. Of course, Linux couldn't feasibly change to GPL3 > because their copyright licensing mo

Re: Trying out Codeberg

Le vendredi 07 mars 2025 à 02:53 +0100, Denis 'GNUtoo' Carikli a écrit : > On Thu, 06 Mar 2025 10:10:03 +0900 > Maxim Cournoyer wrote: > > > > Is Docker the only current solution for runners in the CI? > This is my understanding from my discussion with neox. > > > > Having a less generic solutio

Re: Scaling issues with forges Was: Trying out Codeberg

On Tue, 11 Mar 2025 02:32:42 +0100 Denis 'GNUtoo' Carikli wrote: > Another issue is that we'd probably need to tell contributors not to > expect reviews within the forge. It could be told inside the Guix > manual. And at the end of the day, if contributors don't understand > that, it will probably

Re: Scaling issues with forges Was: Trying out Codeberg

On Mon, 10 Mar 2025 11:37:29 +0100 Simon Tournier wrote: > Yes, this can be fixed with tooling. But that’s the wrong frame for > an answer, IMHO. The question is: who commits in maintaining such > tools? This is a good point. One possibility is that someone write tools and that they are collecti

Re: Scaling issues with forges Was: Trying out Codeberg

On Fri, 7 Mar 2025 15:02:57 -0500 Leo Famulari wrote: > One thing about how Linux solved these issues, is that it Linux became > commercially valuable to the point where they pay people to maintain > the code, which includes reviewing contributions. I used Linux as an example because I know it wa

Re: Scaling issues with forges Was: Trying out Codeberg

On Mon, Mar 10, 2025 at 11:32:37PM +0100, Denis 'GNUtoo' Carikli wrote: > It is possible to require to license things under GPLv2-or-later for > instance, so technically it is not a big issue. VLC also managed to do > license changes, as well as Openstreetmap. It's possible to do GPL2 or later, an

Re: Scaling issues with forges Was: Trying out Codeberg

Hi Simon, Simon Tournier writes: > Yeah, I’m happy with my setup and I shared [3] several times how Emacs + > Notmuch + Org-mode is really nice for me. And I also engaged [4] how > public-inbox can help. Are the relevent portions of your .emacs or init.el accessible somewhere? -- Suhail

Re: Scaling issues with forges Was: Trying out Codeberg

On Mon, 10 Mar 2025 11:37:29 +0100 Simon Tournier wrote: > Hi Denis, all, Hi, > That’s said, we must recognize that sending patches by emails is not > smooth at all. Indeed. The configuration (smtp settings, or learning how to import patches in mail clients before sending them, etc) is probably

linux-libre, Was: Scaling issues with forges Was: Trying out Codeberg

Hi, Note that I also discussed various kernel options at the FOSDEM with other people involved in Guix, so I'm taking the occasion to add the info here as well. On Mon, 10 Mar 2025 10:08:23 +0900 Maxim Cournoyer wrote: > In practice, Linux-libre deals pretty much with a single issue: the > non-f

Re: Scaling issues with forges Was: Trying out Codeberg

On Fri, 7 Mar 2025 15:02:57 -0500 Leo Famulari wrote: > And still you can find endless complaints about their onerous > contribution workflow If more people can send patches, it is indeed very good, but the point of these workflow and tools is also to prioritize the efficient of the maintainers o

Re: Scaling issues with forges Was: Trying out Codeberg

Hi Denis, all, I agree with some points you list here. For instance, using Codeberg, somehow we do not apply the dogfooding principle of “user-autonomy”; as I pointed [1] very early in the discussion. :-) Moreover, it also raises practical considerations as the backup [2] of all the discussions

Re: Scaling issues with forges Was: Trying out Codeberg

Hi Leo, Leo Famulari writes: > On Sun, Mar 09, 2025 at 01:55:46PM +0900, Maxim Cournoyer wrote: >> Which many concessions to pragmatism are you referring to? The only one >> I can think of is allowing devices to load their non-free firmwares, but >> I'm not even sure this was a concession, more

Re: Scaling issues with forges Was: Trying out Codeberg

On Sun, Mar 09, 2025 at 01:55:46PM +0900, Maxim Cournoyer wrote: > Which many concessions to pragmatism are you referring to? The only one > I can think of is allowing devices to load their non-free firmwares, but > I'm not even sure this was a concession, more of a 'I don't care what > code runs

Re: Scaling issues with forges Was: Trying out Codeberg

Hi Leo, Leo Famulari writes: > On Fri, Mar 07, 2025 at 04:39:34PM +0100, Denis 'GNUtoo' Carikli wrote: >> If we look at big projects like Linux, they have faced a similar issue >> in the past and as I understand they solved it by using more adapted >> tools and processes and they even ended up m

Re: Scaling issues with forges Was: Trying out Codeberg

On Fri, Mar 07, 2025 at 04:39:34PM +0100, Denis 'GNUtoo' Carikli wrote: > If we look at big projects like Linux, they have faced a similar issue > in the past and as I understand they solved it by using more adapted > tools and processes and they even ended up making their own software > tools (git

Re: Trying out Codeberg

On Thu, 06 Mar 2025 10:10:03 +0900 Maxim Cournoyer wrote: > > Is Docker the only current solution for runners in the CI? This is my understanding from my discussion with neox. > > Having a less generic solution might be better though, like using > > 'guix' or 'debootstrap' to build containers wi

Re: Trying out Codeberg

Maxim Cournoyer writes: Hi Denis, Denis 'GNUtoo' Carikli writes: On Sat, 22 Feb 2025 22:35:21 +0900 Maxim Cournoyer wrote: [0] https://forge.a-lec.org/ (self-hosted in France by a nonprofit! [1]) [1] https://www.a-lec.org/ Personally I have a private repository on forge.a-lec.org that

Re: Trying out Codeberg

Hi Denis, Denis 'GNUtoo' Carikli writes: > On Sat, 22 Feb 2025 22:35:21 +0900 > Maxim Cournoyer wrote: >> [0] https://forge.a-lec.org/ (self-hosted in France by a nonprofit! [1]) >> [1] https://www.a-lec.org/ > Personally I have a private repository on forge.a-lec.org that I use > for Q/A for

Re: Trying out Codeberg

On Sat, 22 Feb 2025 22:35:21 +0900 Maxim Cournoyer wrote: > [0] https://forge.a-lec.org/ (self-hosted in France by a nonprofit! [1]) > [1] https://www.a-lec.org/ Personally I have a private repository on forge.a-lec.org that I use for Q/A for a project I participate in, and so I push and pull re

Re: Trying out Codeberg

Greg Hogan writes: [...] > git push civodul HEAD:refs/for/master/$(git branch --show-current) \ > -o title="$(git log -1 --pretty=format:'%s')" \ > -o description="$(git log -1 --pretty=format:'%b' | awk 1 ORS='')" > > [0] https://codeberg.org/civodul/guix/pulls/12 > For Emacs users, maybe

Re: Trying out Codeberg

Am 27.02.25 um 15:49 schrieb Greg Hogan: git push civodul HEAD:refs/for/master/$(git branch --show-current) \ -o title="$(git log -1 --pretty=format:'%s')" \ -o description="$(git log -1 --pretty=format:'%b' | awk 1 ORS='')" Untested: The third code-snippet in

Re: Trying out Codeberg

On Fri, Feb 21, 2025 at 3:45 AM Alexis Simon wrote: > > Hello, > > For those interested I tried the AGit workflow [1] on guix-science and > it worked nicely to start a PR from the command line without forking > [2]. Not sure it was mentioned before. I ran the following for a single commit pull re

Re: Posting GCD #002? (was Re: Trying out Codeberg)

GCD 002 is officially submitted now! :-) https://issues.guix.gnu.org/76503 Ludo’.

Re: Posting GCD #002? (was Re: Trying out Codeberg)

Hi, Simon Tournier skribis: > On Sun, 16 Feb 2025 at 17:41, Ludovic Courtès wrote: > >> I’ll be formally posting GCD #002 soon (“Migrating repositories, issues, >> and patches to Codeberg”) > > As discussed elsewhere [1], we need a GCD process in order to amend > Accepted GCDs without running a

Posting GCD #002? (was Re: Trying out Codeberg)

Hi Ludo, On Sun, 16 Feb 2025 at 17:41, Ludovic Courtès wrote: > I’ll be formally posting GCD #002 soon (“Migrating repositories, issues, > and patches to Codeberg”) As discussed elsewhere [1], we need a GCD process in order to amend Accepted GCDs without running a complete dance. My question i

Re: Trying out Codeberg

Hi Simon, Simon Tournier writes: > Hi Efraim, > > On Fri, 21 Feb 2025 at 09:01, Efraim Flashner wrote: > >>What parts of codeberg do you find slow? Is it loading the >> website or navigating between different pages or a different workflow? > > Somehow loading the website and then n

Re: Trying out Codeberg

Hi Efraim, On Fri, 21 Feb 2025 at 09:01, Efraim Flashner wrote: >What parts of codeberg do you find slow? Is it loading the > website or navigating between different pages or a different workflow? Somehow loading the website and then navigate between different pages. But that’s not

Re: Trying out Codeberg

Hello, For those interested I tried the AGit workflow [1] on guix-science and it worked nicely to start a PR from the command line without forking [2]. Not sure it was mentioned before. Alexis [1] https://codeberg.org/forgejo/docs/src/branch/v7.0/docs/user/agit-support.md [2] https://codeb

Re: Trying out Codeberg

Hi, On Tue, 18 Feb 2025 at 13:39, Rostislav Svoboda wrote: > People, I find codeberg to be slow :-/ It’s “slow“ on my side too but not slower than gitlab.com or gitlab.inria.fr or etc. :-) My main annoyance isn’t “slow” but I cannot locally cache. It’s impracticable when you have a poor netw

Re: Trying out Codeberg

Hi Olivier, On Sun, 16 Feb 2025 at 13:51, Olivier Dion wrote: > I have not follow the entire thread about this migration. > > Will the mail-patch workflow still available? The mail-patch workflow is still available. It will be available until a GCD changing is accepted. And such GCD will expl

Re: Trying out Codeberg

Hi Ludo, On Sun, 16 Feb 2025 at 17:41, Ludovic Courtès wrote: >perhaps even before GCD #001 is committed > (not sure what’s going on here :-)) Probably because I’m lagging… Well, now it’s ready from my side. :-) Feel free to tweak, if it’s not clear enough. Cheer

Re: Trying out Codeberg

People, I find codeberg to be slow :-/ Cheers, Bost

Re: Trying out Codeberg

I have not follow the entire thread about this migration. Will the mail-patch workflow still available? On Sun, 16 Feb 2025, Ludovic Courtès wrote: > Hello Guix, > > I’ll be formally posting GCD #002 soon (“Migrating repositories, issues, > and patches to Codeberg”), perhaps even before GCD #0

Re: Trying out Codeberg

Hello Ludo' > 1. try and look at pull requests, but only for trivial packaging > changes (I will close pull requests that don’t fit the bill); Please pull this one: https://codeberg.org/civodul/guix/pulls/3 That's an ideal candidate. It's just a silly Emacs package that "displays a buffer

Trying out Codeberg

Hello Guix, I’ll be formally posting GCD #002 soon (“Migrating repositories, issues, and patches to Codeberg”), perhaps even before GCD #001 is committed (not sure what’s going on here :-)), but before I do, and as a followup to our discussions at the Guix Days, here’s an offer for those who want