Re: Implementing feature requests for a package when a maintainer doesn't respond

[Marc Haber]

On Thu, 12 Jun 2025 14:31:02 -0500, Aaron Rainbolt
 wrote:
>Some time ago, I did a lot of work on getting a U-Boot + grub-efi-arm64
>boot flow to work on the Raspberry Pi 4 with Debian. I was able to get
>a proof-of-concept implementation to work correctly, and was interested
>in upstreaming my work to Debian if it was welcome.

If you had written that two weeks ago I would have saved myself a few
days of work. I spent some time with u-boot on the Raspberry Pi 4 and
am just in the middle of preparing a blog post.

Did you publish your work? Would you mind linking that publication on
the Debian Wiki Raspberry Pi 4 page? I believe that page already has a
place that says that booting grub through u-boot is possible. That
would be the right place to publish your work. You don't need any team
to cooperate to write about your results there.

Does your solution mean that the regular Debian ARM64 installer just
works on the Raspi? Does the resulting system enumerate the hardware
via ACPI or is there a Device Tree? How about having accelerated
Graphics? What did you do to keep the raspi-firmware package from
messing around with /boot/firmware?

Thanks for caring about Debian on the Raspberry Pi!

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Project enquiry

[Leandro Cunha]

No spam, please? Thanks...

Em qui., 12 de jun. de 2025, 22:00, Kroll John 
escreveu:

> Hi
>
>
> We have just completed our plans.
> Would you mind, we send through for a quote
> at your earliest convenience. look forward
> to your response.
>
>
> Regards
>
>
>

Re: New contributor experience

[Otto Kekäläinen]

https://www.debian.org/devel/join/ already says:
"As a prospective developer, you should also subscribe to debian-mentors.
Here you can ask questions about packaging and infrastructure projects as
well as other developer-related issues. Please note that this list is meant
for new contributors, not users."

Inversely this also means that potential mentors should be on that list.
Adding more places to track isn't necessarily useful and in worst case
counterproductive for both mentors and mentees.

Re: New contributor experience

[Pirate Praveen]

On 6/13/25 11:28 AM, Otto Kekäläinen wrote:


https://www.debian.org/devel/join/  
already says:
"As a prospective developer, you should also subscribe to debian- 
mentors. Here you can ask questions about packaging and infrastructure 
projects as well as other developer-related issues. Please note that 
this list is meant for new contributors, not users."


Inversely this also means that potential mentors should be on that list. 
Adding more places to track isn't necessarily useful and in worst case 
counterproductive for both mentors and mentees.




I don't think this is mutually exclusive - being on mentors list means 
you are open to all kinds of newbie questions, anyone interested in any 
team you have to respond. But listing here means only people interested 
in your team will contact you. I can understand trying to consolidate, 
but overwhelming newbies or mentors cannot solve this problem.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1107670: ITP: condense-json -- Python function for condensing JSON using replacement strings

[Antoine Beaupré]

On 2025-06-12 10:50:38, Guillem Jover wrote:
> Hi!
>
> On Wed, 2025-06-11 at 13:43:51 -0400, Antoine Beaupre wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Antoine Beaupre 
>> X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
>
>> * Package name: condense-json
>>   Version : 0.1.3
>>   Upstream Contact: Simon Willison
>> * URL : https://github.com/simonw/condense-json
>> * License : Apache
>>   Programming Lang: Python
>>   Description : Python function for condensing JSON using replacement 
>> strings
>> 
>>  The `condense_json` function searches a JSON-like object for strings
>>  that contain specified replacement substrings. It replaces these
>>  substrings with a compact representation, making the JSON more
>>  concise.
>>  .
>>  This is mostly used as a dependency for the llm package.
>
> Please namespace the source package with python-, so that we do not
> take the global namespace for language specific packages.

Okay! This has already been uploaded to NEW, but I guess I can just
upload a new version to replace it?

The binary package already has the python-* prefix, FWIW, so I figured
it was okay for the source package to be like this...

a.

-- 
The odds are greatly against you being immensely smarter than everyone
else in the field. If your analysis says your terminal velocity is
twice the speed of light, you may have invented warp drive, but the
chances are a lot better that you've screwed up.
- Akin's Laws of Spacecraft Design

Re: New contributor experience

[IOhannes m zmölnig]

Am 11. Juni 2025 21:31:53 MESZ schrieb "Otto Kekäläinen" :
>
>>
>> I have started a new wiki page for this purpose
>>
>> https://wiki.debian.org/Newcomers
>
>All teams can and should welcome and mentor newcomers

that sounds nice.

however, I'm afraid that in practice the "can [...] mentor newcomers" is a bit 
optimistic (at least if "can" means "have the bandwidth to")

eg the multimedia team (which I'm a proud member of) is really not very much of 
a "team" (with people working *together* on a bunch of packages), at least in 
my impression (which might be totally off).
in practice, it is more of a "lowNMU"  team, and that's it.
I don't really see how there would be enough bandwidth to do actual mentoring 
and stuff.

other people might have similar experiences with other teams.

so probably the wiki page should mention "all" the various teams (with links), 
telling people that they can/should/... contact them; but still have a curated 
list of "best practice" teams, that feel like they can invest significantly on 
mentoring.



mfh.her.fsr
IOhannes

Re: Implementing feature requests for a package when a maintainer doesn't respond

[Soren Stoutner]

On Thursday, June 12, 2025 1:36:50 PM Mountain Standard Time Andrey 
Rakhmatullin wrote:
> On Thu, Jun 12, 2025 at 02:31:02PM -0500, Aaron Rainbolt wrote:
> >However, since I haven't
> >gotten any response (no explicit "this would be good, send a patch and
> >let's see what you have", no criticism or discussion, etc.), I don't
> >know how to proceed. I don't want to submit a patch and have it ignored
> >similar to the research and feature requests up to now. I also don't
> >want to just wait indefinitely before implementing patches.
> >
> >I know that for bugfixes, the NMU process can be used to work around an
> >unresponsive maintainer, while still giving the maintainer time to take
> >a look and fix things if they'd like to. But for this kind of a feature
> >addition, I don't know if this is the right approach. As the Debian
> >Developer's Reference [5] says, "Using NMUs to make changes that are
> >likely to be non-consensual is discouraged."
> >
> >What's a good way forward here? Am I trying to do something that
> >fundamentally shouldn't be done, or is there a good way for me to
> >contribute this feature?
> 
> Salvage or hijack, basically.

I would recommend you first create a bug and an associated MR.  Then, if you 
get no response (which is obviously different than a NACK), you can choose if 
you would like to salvage the package or if you would like to leave the MR 
there for someone else who to to come along and salvage the package.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Implementing feature requests for a package when a maintainer doesn't respond

[Aaron Rainbolt]

On Thu, 12 Jun 2025 14:42:33 -0700
Soren Stoutner  wrote:

> On Thursday, June 12, 2025 1:36:50 PM Mountain Standard Time Andrey 
> Rakhmatullin wrote:
> > On Thu, Jun 12, 2025 at 02:31:02PM -0500, Aaron Rainbolt wrote:  
> > >However, since I haven't
> > >gotten any response (no explicit "this would be good, send a patch
> > >and let's see what you have", no criticism or discussion, etc.), I
> > >don't know how to proceed. I don't want to submit a patch and have
> > >it ignored similar to the research and feature requests up to now.
> > >I also don't want to just wait indefinitely before implementing
> > >patches.
> > >
> > >I know that for bugfixes, the NMU process can be used to work
> > >around an unresponsive maintainer, while still giving the
> > >maintainer time to take a look and fix things if they'd like to.
> > >But for this kind of a feature addition, I don't know if this is
> > >the right approach. As the Debian Developer's Reference [5] says,
> > >"Using NMUs to make changes that are likely to be non-consensual
> > >is discouraged."
> > >
> > >What's a good way forward here? Am I trying to do something that
> > >fundamentally shouldn't be done, or is there a good way for me to
> > >contribute this feature?  
> > 
> > Salvage or hijack, basically.  
> 
> I would recommend you first create a bug and an associated MR.  Then,
> if you get no response (which is obviously different than a NACK),
> you can choose if you would like to salvage the package or if you
> would like to leave the MR there for someone else who to to come
> along and salvage the package.

Makes sense. I have a bug already, though I might need to file a new
one to go along with it. I guess then I'll try to salvage it if I can,
assuming the maintainer isn't around. (Maybe they were just busy and
prefer to review real code more than ideas.)


pgpNJRmnCGgyJ.pgp
Description: OpenPGP digital signature

Implementing feature requests for a package when a maintainer doesn't respond

[Aaron Rainbolt]

Some time ago, I did a lot of work on getting a U-Boot + grub-efi-arm64
boot flow to work on the Raspberry Pi 4 with Debian. I was able to get
a proof-of-concept implementation to work correctly, and was interested
in upstreaming my work to Debian if it was welcome. To that end, I
attempted to reach the team taking care of Raspberry Pi support
maintenance in Debian in a few different ways. [1] [2] [3] [4] So far I
haven't gotten much of a response on any platform.

Obviously, I would like to see this feature in upstream Debian at some
point, which is why I did the work to see if it could be done. I'd like
to send patches to implement the feature. However, since I haven't
gotten any response (no explicit "this would be good, send a patch and
let's see what you have", no criticism or discussion, etc.), I don't
know how to proceed. I don't want to submit a patch and have it ignored
similar to the research and feature requests up to now. I also don't
want to just wait indefinitely before implementing patches.

I know that for bugfixes, the NMU process can be used to work around an
unresponsive maintainer, while still giving the maintainer time to take
a look and fix things if they'd like to. But for this kind of a feature
addition, I don't know if this is the right approach. As the Debian
Developer's Reference [5] says, "Using NMUs to make changes that are
likely to be non-consensual is discouraged."

What's a good way forward here? Am I trying to do something that
fundamentally shouldn't be done, or is there a good way for me to
contribute this feature?

[1] https://lists.debian.org/debian-arm/2025/04/msg00012.html
[2] https://salsa.debian.org/raspi-team/image-specs/-/issues/78
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102607
[4] Also reached out via IRC, didn't get much of a response except one
person let me know about the existence of another UEFI
implementation for Raspberry Pi devices.
[5] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu


pgpnHyHlPIGKJ.pgp
Description: OpenPGP digital signature

Re: Implementing feature requests for a package when a maintainer doesn't respond

[Andrey Rakhmatullin]

On Thu, Jun 12, 2025 at 02:31:02PM -0500, Aaron Rainbolt wrote:

However, since I haven't
gotten any response (no explicit "this would be good, send a patch and
let's see what you have", no criticism or discussion, etc.), I don't
know how to proceed. I don't want to submit a patch and have it ignored
similar to the research and feature requests up to now. I also don't
want to just wait indefinitely before implementing patches.

I know that for bugfixes, the NMU process can be used to work around an
unresponsive maintainer, while still giving the maintainer time to take
a look and fix things if they'd like to. But for this kind of a feature
addition, I don't know if this is the right approach. As the Debian
Developer's Reference [5] says, "Using NMUs to make changes that are
likely to be non-consensual is discouraged."

What's a good way forward here? Am I trying to do something that
fundamentally shouldn't be done, or is there a good way for me to
contribute this feature?


Salvage or hijack, basically.




--
WBR, wRAR


signature.asc
Description: PGP signature

Work-needing packages report for Jun 13, 2025

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1178 (new: 0)
Total number of packages offered up for adoption: 129 (new: 0)
Total number of packages requested help for: 53 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 1178 packages are
orphaned.  See https://www.debian.org/devel/wnpp/orphaned
for a complete list.



No new packages have been given up for adoption, but a total of 129 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 2434 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web
   debian-edu-router-deployserver
   debian-edu-router-plugin.content-filter (112 more omitted)
 Installations reported by Popcon: 114466
 Bug Report URL: https://bugs.debian.org/910917

   apparmor (#1006872), requested 1193 days ago
 Description: user-space parser utility for AppArmor
 Reverse Depends: apparmor-notify apparmor-profiles
   apparmor-profiles-extra apparmor-utils dbus-broker dbus-daemon
   dbus-tests debian-cloud-images-packages dovecot-core firejail (32
   more omitted)
 Installations reported by Popcon: 242564
 Bug Report URL: https://bugs.debian.org/1006872

   autopkgtest (#846328), requested 3116 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker rocm-podman-support rocm-qemu-support
   sbuild-qemu
 Installations reported by Popcon: 1332
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 5009 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa
 Installations reported by Popcon: 377
 Bug Report URL: https://bugs.debian.org/642906

   cargo (#860116), requested 2984 days ago
 Description: Rust package manager
 Reverse Depends: cargo-debstatus dh-cargo dh-rust
   python3-setuptools-rust rust-all
 Installations reported by Popcon: 4178
 Bug Report URL: https://bugs.debian.org/860116

   casparcg-server (#1071139), requested 394 days ago
 Description: layered real-time video compositor to multiple outputs
 Installations reported by Popcon: 9
 Bug Report URL: https://bugs.debian.org/1071139

   chromium (#1016047), requested 1052 days ago
 Description: web browser
 Reverse Depends: budgie-desktop-environment chromium chromium-driver
   chromium-headless-shell chromium-l10n chromium-shell qunit-selenium
   x2gothinclient-minidesktop
 Installations reported by Popcon: 26597
 Bug Report URL: https://bugs.debian.org/1016047

   corectrl (#1093892), requested 140 days ago
 Description: Control your computer hardware using application
   profiles
 Installations reported by Popcon: 281
 Bug Report URL: https://bugs.debian.org/1093892

   cron (#984736), requested 1558 days ago
 Description: new maintainer need
 Reverse Depends: apticron autolog backintime-common bcron
   btrfsmaintenance buildd checksecurity clamtk cricket cron (29 more
   omitted)
 Installations reported by Popcon: 251305
 Bug Report URL: https://bugs.debian.org/984736

   cryfs (#1093400), requested 145 days ago
 Description: encrypt your files and store them in the cloud (popcon
   20k)
 Reverse Depends: plasma-vault
 Installations reported by Popcon: 23665
 Bug Report URL: https://bugs.debian.org/1093400

   cyrus-imapd (#921717), requested 2316 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 318
 Bug Report URL: https://bugs.debian.org/921717

   dee (#831388), requested 3254 days ago
 Description: model to synchronize multiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0
   libdee-dev libunity-dev libunity-protocol-private0 libunity-tools
   libunity9 zeitgeist-core
 Installations reported by Popcon: 66081
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 3939 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 1370
 Bug Report URL: https://bugs.debian.org/759995

   dh-ma

Re: Project-wide LLM budget for helping people (was: Re: Complete and unified documentation for new maintainers

[Andreas Tille]

Hi Lucas,

Thank you for bringing up the idea of Debian applying for the OpenAI
Open Source Fund. I appreciate you taking the initiative to explore
potential funding opportunities that could benefit DDs who might decide
freely to profit from it or not.

Since you've asked for DPL approval, I hereby approve your initiative to
explore and apply for the OpenAI Open Source Fund.

Kind regards
Andreas.

Am Thu, Jun 12, 2025 at 09:42:48AM +0200 schrieb Lucas Nussbaum:
> On 11/06/25 at 22:10 +0300, Otto Kekäläinen wrote:
> > Hi!
> > 
> > > > > OpenAI has an Open Source fund. Maybe Debian should apply[1] for a 
> > > > > grant
> > > > > so that Debian contributors could get hands-on experience on how this
> > > > > could help their Debian activities?
> > > >
> > > > or maybe Debian should not.
> > >
> > > Maybe. Honestly, I don't know.
> > 
> > I still think it would be a nice perk for DDs, along the other perks
> > listed at https://wiki.debian.org/MemberBenefits
> > 
> > It is up to each DD to decide how to use the tools and services.
> > Personally I don't recommend using them to generate code as in the
> > Debian context they seem to output so much bad results, but using
> > LLM's for example to review code seems to be working pretty well and
> > is faster and cheaper than waiting for humans to review (and humans
> > can still review, they will just seem more polished stuff).
> 
> My experience is a bit different -- I've found it useful to treat the LLM
> as an inexperienced coworker:
> - decide on what I would like to do
> - ask the LLM to do it
> - review carefully
> - refine what the LLM proposes either by asking with more details, or
>   edit directly
> 
> > > (A) an "agent", that is the client software running on your machine that
> > > you talk with, and that interacts with your codebase (read files, make
> > > changes to files, run commands, create git commits, etc.). Ideally in
> > > some kind of sandbox and/or with permissions management.
> > > Examples include 'Claude Code' (works in CLI, proprietary, interacts
> > > only with Anthropic models), Cursor(.com) (VS Code fork, proprietary,
> > > interacts with either Claude* (Anthropic) or Gemini* (Google)), Codex
> > > CLI (free software, developed by OpenAI and focused on their models, but
> > > supposed to work with other providers). DebGPT fits here too (but is
> > > less advanced for coding tasks than Claude Code or Cursor).
> > 
> > All of the above are closed-source solutions.
> 
> Not Codex CLI
> 
> > I have been playing
> > around with the fully open https://aider.chat/ for well over a year
> > and I would recommend it instead. I hope to some day write a blog post
> > about how I run it inside a container safely and how I have customized
> > it to give better results than what it does out-of-the-box.
> 
> Right, aider.chat came up in another discussion, and looks promising.
> There was an ITP about it (#1082026, abandonned).
> 
> Another Free Software alternative is Zed
> (https://github.com/zed-industries/zed), but it looks less open in the
> spirit than Aider.
> Other closed-source products are WindSurf, Augment Code.
> 
> Lucas
> 
> 

-- 
https://fam-tille.de


signature.asc
Description: PGP signature

Re: Bug#1107670: ITP: condense-json -- Python function for condensing JSON using replacement strings

[Guillem Jover]

Hi!

On Wed, 2025-06-11 at 13:43:51 -0400, Antoine Beaupre wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Antoine Beaupre 
> X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

> * Package name: condense-json
>   Version : 0.1.3
>   Upstream Contact: Simon Willison
> * URL : https://github.com/simonw/condense-json
> * License : Apache
>   Programming Lang: Python
>   Description : Python function for condensing JSON using replacement 
> strings
> 
>  The `condense_json` function searches a JSON-like object for strings
>  that contain specified replacement substrings. It replaces these
>  substrings with a compact representation, making the JSON more
>  concise.
>  .
>  This is mostly used as a dependency for the llm package.

Please namespace the source package with python-, so that we do not
take the global namespace for language specific packages.

Thanks!
Guillem

Re: Project-wide LLM budget for helping people (was: Re: Complete and unified documentation for new maintainers

[Otto Kekäläinen]

> > All of the above are closed-source solutions.
>
> Not Codex CLI

Indeed, I guess I need to try it out now to evaluate it.

> > I have been playing
> > around with the fully open https://aider.chat/ for well over a year
> > and I would recommend it instead. I hope to some day write a blog post
> > about how I run it inside a container safely and how I have customized
> > it to give better results than what it does out-of-the-box.
>
> Right, aider.chat came up in another discussion, and looks promising.
> There was an ITP about it (#1082026, abandonned).

Yes, I am in 'X-Debbugs-Cc' for it as it was my mentee working on it,
but dependencies turned out too complex.

> Another Free Software alternative is Zed
> (https://github.com/zed-industries/zed), but it looks less open in the
> spirit than Aider.

Zed is a full editor, written by the same authors who originally did
Atom at GitHub, which later got killed by Microsoft in their push for
VS Code, and then Atom reincarnated as Pulsar. I still use Pulsar but
might switch to Zed (ITP stalled at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10761659.

Anyway, I am glad if you can contact the major LLM producers and see
if they want to offer free API access to Debian Developers. Healthy
scepticism is good, but we should not categorically dismiss use of
LLMs.

Re: Project-wide LLM budget for helping people

[Simon Richter]

Hi,

On 6/12/25 16:42, Lucas Nussbaum wrote:


My experience is a bit different -- I've found it useful to treat the LLM
as an inexperienced coworker:
- decide on what I would like to do
- ask the LLM to do it
- review carefully
- refine what the LLM proposes either by asking with more details, or
   edit directly


My feeling is that LLMs are not really useful in the context of newcomer 
onboarding, neither as a resource we want to make available to newcomers 
for "easy tasks", nor as a tool to produce documentation aimed at newcomers.


The only thing worse than no documentation is wrong documentation, and 
I've had the "pleasure" of reviewing way too many merge requests where 
someone ran a .pot file through Google Translate and submitted that, or 
had an LLM generate Doxygen documentation for the entire project to make 
the CI warnings about undocumented structs and functions go away.


This is still a compilation process, so it *removes* information. It is 
not reproducible because it also adds randomness, and it merges a 
massive lossily compressed database in the process, but the actual 
information that needs to be conveyed comes from us, and we need to take 
care that any processed form of that information that we publish is 
still accurate. This is further complicated by the fact that the 
database we're merging contains potentially conflicting or outdated 
information.


   Simon

Re: Project-wide LLM budget for helping people (was: Re: Complete and unified documentation for new maintainers

[Lucas Nussbaum]

On 11/06/25 at 22:10 +0300, Otto Kekäläinen wrote:
> Hi!
> 
> > > > OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
> > > > so that Debian contributors could get hands-on experience on how this
> > > > could help their Debian activities?
> > >
> > > or maybe Debian should not.
> >
> > Maybe. Honestly, I don't know.
> 
> I still think it would be a nice perk for DDs, along the other perks
> listed at https://wiki.debian.org/MemberBenefits
> 
> It is up to each DD to decide how to use the tools and services.
> Personally I don't recommend using them to generate code as in the
> Debian context they seem to output so much bad results, but using
> LLM's for example to review code seems to be working pretty well and
> is faster and cheaper than waiting for humans to review (and humans
> can still review, they will just seem more polished stuff).

My experience is a bit different -- I've found it useful to treat the LLM
as an inexperienced coworker:
- decide on what I would like to do
- ask the LLM to do it
- review carefully
- refine what the LLM proposes either by asking with more details, or
  edit directly

> > (A) an "agent", that is the client software running on your machine that
> > you talk with, and that interacts with your codebase (read files, make
> > changes to files, run commands, create git commits, etc.). Ideally in
> > some kind of sandbox and/or with permissions management.
> > Examples include 'Claude Code' (works in CLI, proprietary, interacts
> > only with Anthropic models), Cursor(.com) (VS Code fork, proprietary,
> > interacts with either Claude* (Anthropic) or Gemini* (Google)), Codex
> > CLI (free software, developed by OpenAI and focused on their models, but
> > supposed to work with other providers). DebGPT fits here too (but is
> > less advanced for coding tasks than Claude Code or Cursor).
> 
> All of the above are closed-source solutions.

Not Codex CLI

> I have been playing
> around with the fully open https://aider.chat/ for well over a year
> and I would recommend it instead. I hope to some day write a blog post
> about how I run it inside a container safely and how I have customized
> it to give better results than what it does out-of-the-box.

Right, aider.chat came up in another discussion, and looks promising.
There was an ITP about it (#1082026, abandonned).

Another Free Software alternative is Zed
(https://github.com/zed-industries/zed), but it looks less open in the
spirit than Aider.
Other closed-source products are WindSurf, Augment Code.

Lucas