Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Ricardo Wurmus]

Felix,


On Fri, Mar 07 2025, Ricardo Wurmus wrote:


I'd rather work on Guix.


Then why is there a backlog of bugs?


This is such an odd thing to ask, I cannot convince myself that 
it's a
serious question asked in good faith.  Surely you are not 
suggesting

that my desire to work on Guix rather than doing sysadmin work or
hacking on infrastructure (which I *have* in fact been doing for 
years
in service of the Guix project, even if you might be unaware of 
it)

would be sufficient in reducing the backlog of bugs?

I only see a group of software developers unable to close more 
bugs than

are being opened.

It's not because of technical limitations [...]


I don't know how you can make this claim with confidence.  You 
are, of
course, welcome to reject my experience here, but (like your 
question
above) that's a really odd way of conducting yourself in a 
discussion.


--
Ricardo

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Simon Tournier]

Hi,

I agree with most of Maxim’s message.  I add two points.

On Tue, 04 Mar 2025 at 20:22, Maxim Cournoyer  wrote:

> I see the argument that there's an HTTP API for Forgejo; that's great,
> but it requires that everyone relearn another way of doing something
> that already works well enough for me and others, which I'm not too
> excited about.  I also assume the Forgejo-related tooling, given their
> young age, would not be as mature and missing features in places, and
> that it would require invested time to comfortably do all that can be
> done today in Gnus and Emacs Debbugs, away from the web interface, in
> the environment of choice (Emacs) of perhaps a majority of the Guix
> contributors.

  a) Today, it’s not possible to work offline or by batch.  To my
 knowledge, there is no tool; at least nothing compatible with
 Emacs.

  b) Today, it’s not possible to comment on patches without the
 web-interface, to my knowledge; least nothing compatible with
 Emacs.


( Aside, through my own glasses, it would be a blocker.  But I’ve myopia
  and I know all people do not have the same lenses. ;-) I mean, I agree
  that our workflow reach some limitations and that we need to act now
  for helping the review/merge workload.  Well, I’m adjusting my
  glasses. :-) )


>> Within **30 days** following acceptance of this GCD, committers would
>> migrate all these repositories to https://codeberg.org/guix.
>>
>> For Guix itself, we would decide on a **flag day** 14 days after
>> acceptance of this GCD at the earliest, and 30 days at the latest.  On
>> that day, the official URL of the Guix repository would become
>> https://codeberg.org/guix/guix.git.  A commit would reflect that by
>> updating:
>
> I'd like to suggest extending the 'trial' period to something much
> longer, like a year or so, to make sure our parachute is properly
> installed before jumping the cliff :-).

I agree.  I propose 1. To design the move of the basis of teams in order
to be a bit more incremental [1].  And 2. To help in implementing a
simple one-way bridge [2]: report the open PR inside Debbugs.

Cheers,
simon

1: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier 
Thu, 06 Mar 2025 17:36:29 +0100
id:874j066rqq@gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/874j066rqq@gmail.com
https://yhetil.org/guix/874j066rqq@gmail.com

2: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier 
Thu, 06 Mar 2025 17:35:25 +0100
id:875xkm6rsi@gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/875xkm6rsi@gmail.com
https://yhetil.org/guix/875xkm6rsi@gmail.com

Re: Scaling issues with forges Was: Trying out Codeberg

[Leo Famulari]

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, checkpatch.pl, etc) for the critical parts, and as I
> understand there are also organizational flexibility (different
> subsystems have different ways of working), and subsystems have their
> own mailing list and so on, but they also kept the mailing list
> model precisely because it scales well.

Overall nice email with a lot of well-considered points!

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. And still you can find
endless complaints about their onerous contribution workflow. Of course,
Linux has made many concessions to pragmatism, which had some effect on
its commercial value. Guix is less concessionary so we will struggle to
find funding on a proportional scale, in my opinion.

Re: Guix booth at JDLL in Lyon, France?

[Tanguy Le Carrour]

Hi Julien,


On Tue Mar 4, 2025 at 11:38 AM CET, Julien Lepiller wrote:
> There is a regular event in Lyon, called JDLL (journées du logiciel libre):
> . It will happen end of may this year.

I’ve never been there! 😱


> We have until march 16 to submit a proposal for a talk or a booth. If we can
> gather at least three more people (other than me) who will be coming and give
> a hand, I would like to submit for a booth.

Sounds like a good idea!


> The event is similar to CdL in Toulouse where we have been present for two
> years now. The booth was quite successful, and it's a good occasion to get
> together.

Haven’t been there either! 😅


> Note that the event is mostly French-speaking.
>
> Thoughts? Volunteers?
>
> I'll bring stickers ;)

You got me at "French-speaking", but stickers are nice too! 😉
What about t-shirts? People asked me about that at Guix Days. Some feel that we
lack a "visual identity" (my words) when gathering. I have the kakemono ready, 
though! 😎

So, I added the event to my agenda and do my best to be there! Looking forward
to it! 😁


-- 
Tanguy

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Ricardo Wurmus]

Divya Ranjan  writes:


We have a *humongous* backlog of patches, [...]


[...] we host a backend service that regularly checks the 
Codeberg

repository for any new issues or PRs and then communicates to us
through the Codeberg’s Forgejo API [0] the content of said 
issues and
PRs. The data received from the API then gets directed to our 
Debbugs
or Mumi backend, which parses the information from it and opens 
a new
Debbugs issue for it. Thus, for every issue opened on Codeberg, 
we

have a mirrored Debbugs issue [...]


So at the end we'd have an even larger backlog of patches, and 
spread
across two systems...?  And where do we source the time and 
motivation
to hack on yet another piece of software?  Outside contributions 
to mumi

have been *very* few in all these years; that's not for a lack of
problems we've had with the system, and for once it's not for a 
lack of

review either.

As a long time contributor with commit access I have the 
impression that

people new to Guix hold the assumption that the current system and
workflow works for long time contributors.  I may just be wildly
incompetent, but for me it most assuredly does not work in 
enabling
reviews.  I mostly review patches that were sent to me directly or 
that
happen to solve a problem I'm trying to solve as part of my 
maintainance

work.

The haphazard GNU fork of Debbugs also lacks a number of features, 
has
odd unaddressed bugs, lacks people who even understand in what 
ways it
differs from the Debian version, lacks people working on improving 
it
and addressing these issues.  (There is literally *one* person who 
keeps

the lights on.)

It does not even do simple things like delivering notifications to
*everyone* who participates in an issue discussion.  This is the 
reason

for the sudden eery silence that can be seen in many issues.

I honestly have my doubts that the move to Codeberg would 
automatically

solve all of my workflow issues, but let's please not eulogize the
email-based workflow too much.  It makes sense to me to base our 
efforts
on a system that is *actively* developed by a *team* of aligned 
free

software hackers.

I don't see an active future for the GNU fork of Debbugs, and I 
think it
is not a good use of our time to work on a system that won't 
improve
unless we burden ourselves with even more work (like taking over 
hosting

and administration).  I'd rather work on Guix.

--
Ricardo

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

[Hilton Chain]

On Fri, 07 Mar 2025 01:24:28 +0800,
Efraim Flashner wrote:
>
> > 4. Check module diff, content of sources marked as TODO and output of
> > 'check-for-pregenerated-files phase.
>
> After the backdoor in xz being hidden in a test tarball I'm not going to
> suggest we drop scanning the test directories, but if we were to go
> through the cargo sources and delete tests and examples it would make
> them a bit smaller and also speed up that phase.

Sure, this can be done.  These sources won't show up in ‘guix build --source’
result anyway.

> I decided to go for uv, which is a python package manager.  The TODO
> comments were good, and I believe I unbundled everything from them.  I
> mostly copied the snippets from the existing packages, but as we package
> more they'll transition over to rust-crates.scm and we'll be able to
> copy changes from there.
>
> I had 4 dependencies which needed git-fetch, and I packaged them in
> rust-crates.scm also.  I tried changing the names to
> rust-xx-for-uv.tar.gz, but that didn't trick cargo into unpacking them.
> In the end I had to add them as inputs and copy them over manually.  One
> of them, version-ranges, was inside a directory of another one, which
> was annoying to figure out, and I think would've needed manual
> intervention even if git sources were unpacked automagically.

pubgrub is a workspace, so it need to be packaged standalone.  The other 3 look
like valid use cases to add back the support :)

> I copied the arguments from fish for the modules and the
> 'prepare-cargo-build-system phase, which was really nice.  Then I had
> another couple of phases I had to add myself; the 'install phase from
> pyproject didn't handle binaries, 'install-extras had to generate the
> shell completions and I spent some time figuring out if there were man
> pages.
>
> Overall I think I spent about 3 hours packaging uv.  uv itself has a 10
> minute build time on my machine, the check for binary files took about
> 60 seconds and each attempt to run the tests took an additional 10
> minutes.  I'm not sure how many crates already exist in crates-* modules
> or which ones would need updating if we did it traditionally, but I
> spent most of the time fighting the 'install and 'check phases.
> Considering we don't care about the input crates except for the licenses
> and security problems, using cargo-audit and cargo-license really did a
> great job of taking care of all of that.
>
> I've attached the 2 patches I created.  I like how I only needed to
> fight with the final package to get it to work.  And I really like the
> 'prepare-cargo-build-system combo phase that can be dropped into other
> packages as needed.  I think we should see about switching some of the
> other packages from the cargo-build-system back to their preferred build
> system.

As replied in Go related thread, I'm thinking of maintaining rust-crates.scm
separately, in a dedicated repo or branch, doing cleanup only in scheduled time
and maybe adding versions to *-cargo-inputs as well.

Then this file will be compatible with most changes on the main branch.
Whenever there's conflict in rust-crates.scm, just copy the file over.

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Development of GNU Guix and the GNU System distribution.]

Hi Ricardo,

On Fri, Mar 07 2025, Ricardo Wurmus wrote:

> I'd rather work on Guix.

Then why is there a backlog of bugs?

I only see a group of software developers unable to close more bugs than
are being opened.

It's not because of technical limitations, but because the committers
are overwhelmed by the overall bug volume, are afraid to trigger
rebuilds or make other big changes, and are generally overworked
volunteers who also want to do other things in their lives.

> I don't see an active future for the GNU fork of Debbugs

There could be.  I mated Debbugs with Public Inbox.

My system scans Debbugs for changes [1] but does not yet maintain
inboxes by bug number.  The information is available via the NNTP news
protocol, for example with the Gnus configuration below.  People could
subscribe to bugs via a news reader and reduce their mail load.

> [Debbugs] does not even do simple things like delivering notifications
> to *everyone* who participates in an issue discussion.

Debbugs does not copy folks automatically because many do not want it.
In Debian, submitters are often non-technical people.  They do not care
about how a problem is solved, only when it is.  Debbugs does that.

Kind regards
Felix

[1] https://patchwise.org/inbox/bugs-to-scan/

* * *

(setq gnus-select-method
  '(nnimap "patchwise.org"
   (nnimap-authenticator anonymous)
   (nnimap-port "imap")
   (nnimap-stream network)))

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Andreas Enge]

Hello,

Am Fri, Mar 07, 2025 at 09:40:28AM -0500 schrieb Suhail Singh:
> Based on Andreas's observations in [1]:
> It seems if we are basing our experimentations on only "trivial patches"
> that are sent to , we may not be
> observing the instances where a forge-style review process actually
> struggles; our conclusions may be flawed.

my observation was rather the inverse: our current debbugs approch
struggles for patch series. For the submitters, this starts with a
series of size 2 (whenever I have one of these, I look up the Guix
manual on the web and follow the process described there; yet another
example where what I do is actually web based). For reviewers and
committers, series with a few commits are still okay.

Which says nothing about the experience on a forge, logically.

Andreas

Re: Trying out Codeberg

[Denis 'GNUtoo' Carikli]

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 within the forgejo, but
> > that also require volunteers to implement that.  
> 
> We already have Docker image generation support via 'guix pack -f
> docker', and also 'guix system image -t docker' so that should be
> feasible yes.
I'm aware of that. My point with using 'guix' or debootstrap was to find
ways not to have to run a docker registry.

Denis.


pgpKHzsBfN71w.pgp
Description: OpenPGP digital signature

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Suhail Singh]

Andreas Enge  writes:

> my observation was rather the inverse: our current debbugs approch
> struggles for patch series.

Ah, my bad.  I mistook "issues" to mean issues on a forge as opposed to
a debbugs issue.  Thank you for correcting.

> Which says nothing about the experience on a forge, logically.

True.

-- 
Suhail

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Suhail Singh]

Ludovic Courtès  writes:

> As for experimenting, I agree and I reiterate my invitation to send
> trivial patches to  (or to
> Guix-Science, Guix-Past, etc.).  I think this GCD’s discussion period is
> the right time to give it a try as it can better inform discussions.

Based on Andreas's observations in [1]:

#+caption: 
#+begin_quote
  On the other hand, as soon as there is a patch series on issues, it also
  becomes more or less unreadable; after 5 versions of a 6-patch series,
  it becomes difficult to find the start of the current version and all
  comments in between.
#+end_quote

It seems if we are basing our experimentations on only "trivial patches"
that are sent to , we may not be
observing the instances where a forge-style review process actually
struggles; our conclusions may be flawed.

[1]: 

-- 
Suhail

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Andreas Enge]

Hello,

I also agree that we should either not switch, or switch with a short
period of overlap. It does not make sense to spread our limited time to
work on two systems at the same time. And it definitely does not make
sense to spend additional development work (by whom?) to create a bridge
between the two.

Am Fri, Mar 07, 2025 at 10:21:48AM +0100 schrieb Ricardo Wurmus:
> It does not even do simple things like delivering notifications to
> *everyone* who participates in an issue discussion.  This is the reason
> for the sudden eery silence that can be seen in many issues.

And it is something I learnt just recently after more than ten years of
contributing to Guix! If I understood correctly, it does not even alert
the original submitter. Probably I have closed a few issues because the
submitter had not read my comments or request for more information and
I had deduced that they were no longer interested. This alone would be a
reason for me to switch to a different system. We claim that our workflow
is "email based", but in fact it is not: To be informed about issues I
have contributed to, I need to keep each and every one in a bookmark and
visit it with my web browser regularly. At least in the forges I have seen
so far, I get an (often cryptic) email message when something happens
that entices me to connect to the web.

Anyway, I usually look at QA and the issues on the web when I have time
for a little committer work. The situation in which email works is when
I get an automatic copy for a patch touching one of my teams (and this
is very useful).

The overly graphic nature of these web forges makes them somewhat
confusing. For instance, it took me a little while to understand where
the trivial little patch was for an issue on Ludovic's test instance,
until I realised I needed to click once more. issues.guix.gnu.org is
much more focussed and less cluttered.

On the other hand, as soon as there is a patch series on issues, it also
becomes more or less unreadable; after 5 versions of a 6-patch series,
it becomes difficult to find the start of the current version and all
comments in between.

Andreas

Re: Guix booth at JDLL in Lyon, France?

[Luis Felipe]

On 7/03/25 8:53, Tanguy Le Carrour wrote:

On Thu Mar 6, 2025 at 1:52 PM CET, Luis Felipe wrote:

And it goes with the kakemono.

🤔

The kakemono doesn’t have the lambda sun logo. Do you mean it’s the same yellow?


Yes, the color.



OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

New committer

[Greg Hogan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

We have a C++ team! Has the survey shown that project contributors are
happier when members of a team and those patches reviewed more promptly?

I find Guix to be a powerful tool with unbounded potential. Thank you to
all who have contributed. My particular use has been creating shared
build environments with a focus on C++ development. My hope is to use
the teams/branches workflow to provide more and more timely updates to
these packages.

Greg Hogan
keyname: oom

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEACqqo0II8/K7184U726ydBPP7vMFAmfLJLUACgkQ726ydBPP
7vObbQ//f9Dqiq7mlRNWWuoQwmUoRGjxKC33Qhfxbbm2Z4AKYbFxbGia0dIXysWa
bEwqjEK1kqCtg0ocIpoKzcfQMpZnAxzvhnh7zbM3Xl2xGJra4Xcsr0NCo3asdA+Q
YLClf7yXvO8iuBKIHrSvvF2ZVuV9xNYXBJBQqbTs2EAHgIjXOQFFYnbXQqnr0nwS
I1/C0Az0Pv3DIln2jZxUuP+RixAQvnT7fU4s7SVd3/5cy1NfG8ghW17Y3GW+R4EY
4sApykYvaS/2wRNpxtM+u8G6G7pMU8cjKVEzwMdGcmKI2SA312ZlT3dPu3+hEYBo
e+loBDtxXaMq2l4ZIQKh+27lbIHzktOXzLCmLGLgPdKM7x9H/HvaIJ+g3PCPuqp8
Ae6rHopWfgnSVYMoSEdlpWnJmiUL9l2qY3/3on7SypoPrY/6IXl761mtUWgAwiIX
PwrFUNco4cLHkMJqAxfkhG88tW+NYKwH1Zdv7mJcZI/gH4jP6/NWuG5hzvfhxfNo
OBZxwCYSJA1fY3WHQkznaVxSjxE6vmUfUNfjhEpOCvIoRnAcBYRFAtbGBtP5B/RC
hWWF7Pe22Ey8hI20wzYDTrhQ7LBbxxV1CCtsEmh43VntQEHJHvuZJFTsdn10xMcS
ky7KuxcQGD3mZFa/ZnkSz3bw88nZ35LLr0C8Y80O7qbUxHxAfgE=
=V0lC
-END PGP SIGNATURE-

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Development of GNU Guix and the GNU System distribution.]

Hi Ricardo,

On Fri, Mar 07 2025, Ricardo Wurmus wrote:

> Surely you are not suggesting that my desire to work on Guix [...]
> would be sufficient in reducing the backlog of bugs?

The remainder of my message made that clear but you were offended and
hit reply too fast.

My observation was about the group.  I suggested as a hook for my
argument that your desire to contribute, which you have done more than
most, was not sufficient to reduce the backlog of bugs.

Isn't that how you and many other committers feel as well?

Kind regards
Felix

P.S. Questioning my good faith or my conduct was below the belt.

Re: Guix booth at JDLL in Lyon, France?

[Luis Felipe]

On 6/03/25 7:56, Tanguy Le Carrour wrote:

You got me at "French-speaking", but stickers are nice too! 😉
What about t-shirts? People asked me about that at Guix Days. Some feel that we
lack a "visual identity" (my words) when gathering. I have the kakemono ready, 
though! 😎


Just chiming in to suggest using the Guix Lambda Sun design for those 
kinds of events; not only to have a visual identity but to make 
yourselves stand out from the crowd.


Design: 
https://codeberg.org/luis-felipe/guix-graphics/src/branch/trunk/promotional/lambda-sun
Example T-shirt: 
https://um4no.creator-spring.com/listing/gnu-guix-lambda-sun-oam


«Just look for the yellow/orange spot». And it goes with the kakemono.

The design is libre, so you can use it to print whatever you want where 
you live.


Cheers,



OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Guix booth at JDLL in Lyon, France?

[Tanguy Le Carrour]

Hi Luis Felipe,


On Thu Mar 6, 2025 at 1:52 PM CET, Luis Felipe wrote:
> On 6/03/25 7:56, Tanguy Le Carrour wrote:
>> You got me at "French-speaking", but stickers are nice too! 😉
>> What about t-shirts? People asked me about that at Guix Days. Some feel that 
>> we
>> lack a "visual identity" (my words) when gathering. I have the kakemono 
>> ready, though! 😎
>
> Just chiming in to suggest using the Guix Lambda Sun design for those 
> kinds of events; not only to have a visual identity but to make 
> yourselves stand out from the crowd.
>
> Design: 
> https://codeberg.org/luis-felipe/guix-graphics/src/branch/trunk/promotional/lambda-sun
> Example T-shirt: 
> https://um4no.creator-spring.com/listing/gnu-guix-lambda-sun-oam
>
> «Just look for the yellow/orange spot».

Thanks for the links… and the designs, they look great! I like the yellow one!


> And it goes with the kakemono.

🤔

The kakemono doesn’t have the lambda sun logo. Do you mean it’s the same yellow?


-- 
Tanguy

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Divya Ranjan]

Hello Ricardo,

>> We have a *humongous* backlog of patches, [...]
>
>> [...] we host a backend service that regularly checks the Codeberg
>> repository for any new issues or PRs and then communicates to us
>> through the Codeberg’s Forgejo API [0] the content of said issues
>> and
>> PRs. The data received from the API then gets directed to our
>> Debbugs
>> or Mumi backend, which parses the information from it and opens a
>> new
>> Debbugs issue for it. Thus, for every issue opened on Codeberg, we
>> have a mirrored Debbugs issue [...]
>
> So at the end we'd have an even larger backlog of patches, and spread
> across two systems...? [...]

We would have that regardless of whether one follows my proposition or not. The 
old backlog is going nowhere. Even if we make a full-switch to Codeberg 
immediately, the committers would either have to work on both things 
tenaciously as they (committers such as Maxime) get used to an entirely new 
workflow. What is the probability that such an immediate increase in 
responsibilities will not lead to a further increase of existing backlog?

I don’t think anything can solve the backlog quickly, what I proposed was with 
the intent of solving the issue of committers not having to learn a new 
workflow altogether to work on the backlog, ergo, not having another hurdle to 
it amidst a list of others.

> And where do we source the time and motivation
> to hack on yet another piece of software?  Outside contributions to
> mumi have been *very* few in all these years; that's not for a lack of
> problems we've had with the system, and for once it's not for a lack
> of
> review either.

Indeed, that is a problem. It was a mere proposition, so if enough people want 
it to happen, we can have it :)


> As a long time contributor with commit access I have the impression
> that
> people new to Guix hold the assumption that the current system and
> workflow works for long time contributors.  I may just be wildly
> incompetent, but for me it most assuredly does not work in enabling
> reviews.  I mostly review patches that were sent to me directly or
> that
> happen to solve a problem I'm trying to solve as part of my
> maintainance
> work.

I acknowledge your experience, but we heard from others such as Maxime how to 
them it might require learning and changing the workflow. So the people for 
whom the email-based workflow works isn’t really a null set.

> The haphazard GNU fork of Debbugs also lacks a number of features, has
> odd unaddressed bugs, lacks people who even understand in what ways it
> differs from the Debian version, lacks people working on improving it
> and addressing these issues.  (There is literally *one* person who
> keeps
> the lights on.)
>
> It does not even do simple things like delivering notifications to
> *everyone* who participates in an issue discussion.  This is the
>  reason
> for the sudden eery silence that can be seen in many issues.
>
> I honestly have my doubts that the move to Codeberg would
> automatically
> solve all of my workflow issues, but let's please not eulogize the
> email-based workflow too much.  It makes sense to me to base our
> efforts
> on a system that is *actively* developed by a *team* of aligned free
> software hackers.
>
> I don't see an active future for the GNU fork of Debbugs, and I think
> it
> is not a good use of our time to work on a system that won't improve
> unless we burden ourselves with even more work (like taking over
> hosting
> and administration).  I'd rather work on Guix.

By all means, but I think you are confusing a plea for not breaking certain 
people’s workflow as a means to "eulogize" something. The goal here is to 
simply not put enough pressure on people who already have a lot on themselves 
to change their workflow in order to continue contributing to Guix. And my 
proposal is targetted towards an eventual move to Codeberg, just a more gradual 
approach, based on empirical feedback and with some time to clear the existing 
backlog and to learn the new system. 

Regards,
-- 
Divya Ranjan,
Philosophy, Mathematics, Libre Software.

PGP Fingerprint: F0B3 1A69 8006 8FB8 096A  2F12 B245 10C6 108C 8D4A

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Divya Ranjan]

Hello Suhail,

> "Thompson, David"  writes:
>
>> The email-based workflow worked well enough in the early days, but
>> Guix outgrew it 5+ years ago.
>
> Do you also believe that the Linux kernel has outgrown the "email-based
> workflow"?  If not, what makes things different for Guix, in your
> opinion?
>

Despite me being in support of a workflow that doesn’t require opening a 
browser, while thinking about how Linux kernel does it and Guix, I had to 
realize that Linux gets a *lot* more in funding and infrastructure than Guix. 
Of course part of it is because of sheer technological necessity of handling a 
30M LOC project that’s used by everyone. But it’s also because they *can* get 
it, through the help of Linux Foundation and so on.

I don’t think we have that many degrees of freedom here, so we need to be 
careful about our resources, and the work of volunteers and committers. I would 
be open to a consideration of using BugZilla or Gerrit for that matter, even 
though I’m not used to them, the possibility of working with them without a 
browser, motivates me to learn them.

Regards,
-- 
Divya Ranjan,
Philosophy, Mathematics, Libre Software.

PGP Fingerprint: F0B3 1A69 8006 8FB8 096A  2F12 B245 10C6 108C 8D4A

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ricardo Wurmus]

Suhail Singh  writes:


Ludovic Courtès  writes:

As for experimenting, I agree and I reiterate my invitation to 
send

trivial patches to  (or to
Guix-Science, Guix-Past, etc.).  I think this GCD’s discussion 
period is
the right time to give it a try as it can better inform 
discussions.


Based on Andreas's observations in [1]:

#+caption: 
#+begin_quote
  On the other hand, as soon as there is a patch series on 
  issues, it also
  becomes more or less unreadable; after 5 versions of a 6-patch 
  series,
  it becomes difficult to find the start of the current version 
  and all

  comments in between.
#+end_quote

It seems if we are basing our experimentations on only "trivial 
patches"
that are sent to , we may not 
be
observing the instances where a forge-style review process 
actually

struggles; our conclusions may be flawed.


We have had non-trivial patches with a number of revisions on the
guix-science channel.

Examples:

https://codeberg.org/guix-science/guix-science/pulls/59
https://codeberg.org/guix-science/guix-science/pulls/75

--
Ricardo

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Suhail Singh]

"Thompson, David"  writes:

> The email-based workflow worked well enough in the early days, but
> Guix outgrew it 5+ years ago.

Do you also believe that the Linux kernel has outgrown the "email-based
workflow"?  If not, what makes things different for Guix, in your
opinion?

Since a number of criticisms about the current approach have been about
the GNU fork of Debbugs.  I wonder if replacing that with something else
(say, Bugzilla) while still retaining the email-based workflow wouldn't
address most of the pain points.  Unless I'm mistaken, I believe the
Linux kernel takes a similar approach.

-- 
Suhail

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Suhail Singh]

Divya Ranjan  writes:

> I had to realize that Linux gets a *lot* more in funding and
> infrastructure than Guix.

While I agree in general, I don't understand the specific point you were
making.  Was it that Linux with its greater funding has someone to
manage something like Bugzilla, where Guix may not?

> I don’t think we have that many degrees of freedom here, so we need to
> be careful about our resources, and the work of volunteers and
> committers.

Agreed.

-- 
Suhail

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Thompson, David]

Hello,

On Sun, Feb 23, 2025 at 10:21 AM Ludovic Courtès  wrote:
>
> Hello Guix!
>
> This is the formal submission of “Migrating repositories, issues, and
> patches to Codeberg” (GCD 002), a preliminary draft of which I posted
> before the Guix Days⁰.

I support this proposal! It's about time! The email-based workflow
worked well enough in the early days, but Guix outgrew it 5+ years
ago. Savannah is a dead platform and I have long since given up trying
to deal with debbugs for anything other than small patches. I look
forward to being able to easily browse issues and scan through pull
requests.

- Dave

Re: New committer

[Ekaitz Zarraga]

On 2025-03-07 17:55, Greg Hogan wrote:

We have a C++ team! Has the survey shown that project contributors are
happier when members of a team and those patches reviewed more promptly?

I find Guix to be a powerful tool with unbounded potential. Thank you to
all who have contributed. My particular use has been creating shared
build environments with a focus on C++ development. My hope is to use
the teams/branches workflow to provide more and more timely updates to
these packages.

Greg Hogan
keyname: oom




Welcome Greg.

:)

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Suhail Singh]

"Thompson, David"  writes:

>> Do you also believe that the Linux kernel has outgrown the "email-based
>> workflow"?  If not, what makes things different for Guix, in your
>> opinion?
>
> I don't contribute to Linux so I have nothing to add here.

I don't believe that that's a necessary pre-requisite to be able to add
something of value, but fair enough.

>> Since a number of criticisms about the current approach have been about
>> the GNU fork of Debbugs.  I wonder if replacing that with something else
>> (say, Bugzilla) while still retaining the email-based workflow wouldn't
>> address most of the pain points.  Unless I'm mistaken, I believe the
>> Linux kernel takes a similar approach.
>
> I wouldn't support a switch to Bugzilla or something similar.

Okay.

> I want Guix to use a real forge with pull requests, webhooks, etc.

Well, yes, that much is clear.

-- 
Suhail

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Leo Famulari]

On Fri, Mar 07, 2025 at 01:49:46PM -0500, Suhail Singh wrote:
> While I agree in general, I don't understand the specific point you were
> making.  Was it that Linux with its greater funding has someone to
> manage something like Bugzilla, where Guix may not?

Linux contributors and maintainers are paid to be persistent in
reviewing and landing patches, regardless of the tools and workflow.
There are thousands of them, mostly professionals.

As Guix's number 8 commit author and committer (two different stats,
both #8), I can say that I'd be doing Much More these days if it was my
job and not a personal hobby.

git shortlog -ns
git shortlog -ncs

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

[Thompson, David]

On Fri, Mar 7, 2025 at 12:40 PM Suhail Singh  wrote:
>
> "Thompson, David"  writes:
>
> > The email-based workflow worked well enough in the early days, but
> > Guix outgrew it 5+ years ago.
>
> Do you also believe that the Linux kernel has outgrown the "email-based
> workflow"?  If not, what makes things different for Guix, in your
> opinion?

I don't contribute to Linux so I have nothing to add here.

> Since a number of criticisms about the current approach have been about
> the GNU fork of Debbugs.  I wonder if replacing that with something else
> (say, Bugzilla) while still retaining the email-based workflow wouldn't
> address most of the pain points.  Unless I'm mistaken, I believe the
> Linux kernel takes a similar approach.

I wouldn't support a switch to Bugzilla or something similar. I want
Guix to use a real forge with pull requests, webhooks, etc.

- Dave