Creating a C/C++ team?

Creating a C/C++ team?

[Greg Hogan]

Guix,

Should we have a C++ team? I think project contributions regarding C
and C++ compilers, libraries, tools, and programs would benefit from a
tag to flag, discuss, and triage issues and a team branch to manage,
test, and pre-build patches.

This team would of course be distinct from the core-packages team,
which manages the most fundamental packages and challenging updates.

Updates to C++ packages often result in a non-trivial number of
dependent package builds, which makes patch review challenging and
leads to overlooked or forgotten contributions and long-delayed
merges. Also, widely used Guix C++ packages are several versions and
many years out-of-date. A C++ team would help us to be more responsive
both to contributors and upstream releases while maintaining a stable
rolling-release and making efficient use of build farm compute and
storage.

Greg

diff --git a/etc/teams.scm b/etc/teams.scm
index fe3291f914..e257650a04 100755
--- a/etc/teams.scm
+++ b/etc/teams.scm
@@ -611,0 +612,14 @@ (define-team zig
+(define-team c++
+  (team 'c++
+        #:name "C/C++ team"
+        #:description
+        "C and C++ compilers, libraries, tools, and programs"
+        #:scope (list "gnu/packages/c.scm"
+                      "gnu/packages/cpp.scm"
+                      "gnu/packages/llvm.scm"
+                      "gnu/packages/llvm-meta.scm"
+                      "gnu/packages/ninja.scm"
+                      "gnu/packages/valgrind.scm"
+                      "gnu/build/cmake-build-system.scm"
+                      "gnu/build-system/cmake.scm")))
+

Re: Creating a C/C++ team?

[Ludovic Courtès]

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> Should we have a C++ team? I think project contributions regarding C
> and C++ compilers, libraries, tools, and programs would benefit from a
> tag to flag, discuss, and triage issues and a team branch to manage,
> test, and pre-build patches.
>
> This team would of course be distinct from the core-packages team,
> which manages the most fundamental packages and challenging updates.

That makes a lot of sense to me.

> Updates to C++ packages often result in a non-trivial number of
> dependent package builds, which makes patch review challenging and
> leads to overlooked or forgotten contributions and long-delayed
> merges. Also, widely used Guix C++ packages are several versions and
> many years out-of-date. A C++ team would help us to be more responsive
> both to contributors and upstream releases while maintaining a stable
> rolling-release and making efficient use of build farm compute and
> storage.

All for it.  I feel bad when you and others contribute tricky C++
package updates and they remain in the patch queue for weeks or months.

(Speaking of which, I hope you also get commit rights soon, which should
help boost this team’s work.)

Thanks for all the work so far and for the exciting perspective!

Ludo’.

Re: Creating a C/C++ team?

[Liliana Marie Prikler]

Hi Greg,

Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:
> Guix,
> 
> Should we have a C++ team? I think project contributions regarding C
> and C++ compilers, libraries, tools, and programs would benefit from
> a tag to flag, discuss, and triage issues and a team branch to
> manage, test, and pre-build patches.
> 
> This team would of course be distinct from the core-packages team,
> which manages the most fundamental packages and challenging updates.
I think there is a risk that this still overlaps with core-packages on
the account of GCC being our main C/C++ toolchain.

Note: while I'm already swamped with work on gnome and emacs, I would
be interested in joining a hypothetical c++ team.

> diff --git a/etc/teams.scm b/etc/teams.scm
> index fe3291f914..e257650a04 100755
> --- a/etc/teams.scm
> +++ b/etc/teams.scm
> @@ -611,0 +612,14 @@ (define-team zig
> +(define-team c++
> +  (team 'c++
> +        #:name "C/C++ team"
> +        #:description
> +        "C and C++ compilers, libraries, tools, and programs"
I would limit the scope to "libraries and tools".  That programs happen
to be written in C/C++ is almost always incidental :)

> +        #:scope (list "gnu/packages/c.scm"
> +                      "gnu/packages/cpp.scm"
Of course.

> +                      "gnu/packages/llvm.scm"
> +                      "gnu/packages/llvm-meta.scm"
Not sure about these two.  Since our main use for LLVM is in
Rust/Zig/Mesa, all of which have their own teams, maybe we should leave
a broader LLVM team with members from all of that open for folks who
are not necessarily interested in the rest of C/C++.

> +                      "gnu/packages/ninja.scm"
> +                      "gnu/packages/valgrind.scm"
If we add these, I would also suggest adding build-tools.scm,
check.scm, debug.scm etc.

> +                      "gnu/build/cmake-build-system.scm"
> +                      "gnu/build-system/cmake.scm")))
These are under guix/ and belong to the core team IIRC.

Cheers

Re: Creating a C/C++ team?

[Ludovic Courtès]

Hi!

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:

[...]

>> This team would of course be distinct from the core-packages team,
>> which manages the most fundamental packages and challenging updates.
> I think there is a risk that this still overlaps with core-packages on
> the account of GCC being our main C/C++ toolchain.
>
> Note: while I'm already swamped with work on gnome and emacs, I would
> be interested in joining a hypothetical c++ team.
>
>> diff --git a/etc/teams.scm b/etc/teams.scm
>> index fe3291f914..e257650a04 100755
>> --- a/etc/teams.scm
>> +++ b/etc/teams.scm
>> @@ -611,0 +612,14 @@ (define-team zig
>> +(define-team c++
>> +  (team 'c++
>> +        #:name "C/C++ team"
>> +        #:description
>> +        "C and C++ compilers, libraries, tools, and programs"
> I would limit the scope to "libraries and tools".  That programs happen
> to be written in C/C++ is almost always incidental :)

Yes, the description could clarify that Greg wrote above, which is that
its scope is disjoint from that of the ‘core-packages’ team.

Ludo’.