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’.

Re: Creating a C/C++ team?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

On Fri, Nov 29, 2024 at 10:36:13AM +0100, Liliana Marie Prikler wrote:
> 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.

As someone who is in more teams than I mean to be, I wouldn't mind some
overlap between the different teams.  Likely the default llvm hasn't
been upgraded still because no one wants to be the one to break
something.  Also its nice when someone else is able to take something
off your plate.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]