Am Donnerstag, dem 05.12.2024 um 18:35 -0500 schrieb Greg Hogan: > v2 below. Removed compiler (llvm[-meta].scm) scope and removed > "compilers" from description. > > +1 to an LLVM team or llvm[-meta].scm in the core-packages scope. > > I think cmake-build-system belongs in the C++ team scope. Our use of > cmake is rather simple, even with the enhancements collected in > #70031 (which began with a desire to parallelize tests). We should > keep cmake up-to-date without bothering core-packages. I think we can do smaller topic-branches, regardless of which team ought to do the review work. There could even be multiple teams on a particular series, to push it more quickly.
> ninja.scm and valgrind.scm are essentially single package modules. > The suggested build-tools.scm, check.scm, and debug.scm are a mix. > For example, check.scm includes python-pytest among other python > packages. Not sure why these are not in python-check.scm unless there > would be circular dependencies. Given the success of the teams > workflow, should we look to divide these mixed modules by team rather > than grouping by theme? In my opinion, we shouldn't be that exclusionary w.r.t. non-C languages. Tools being written in Python historically hasn't stopped C++ users from adopting them – see Meson or Conan for some popular examples. > $ ./etc/teams.scm show c++ > id: c++ > name: C/C++ team > description: C and C++ libraries and tools and the CMake build > system. > + Note that updates to fundamental packages are the competency of the > + core-packages team. I would just shorten that to "C/C++ libraries and tools", with the CMake build system being one of said tools :) Blasting notes into the team description is imho not a good idea. > scope: > + gnu/build-system/cmake.scm > + gnu/build/cmake-build-system.scm > + gnu/packages/c.scm > + gnu/packages/cmake.scm > + gnu/packages/cpp.scm > + gnu/packages/ninja.scm > + gnu/packages/valgrind.scm Scope looks good enough, even while bikeshedding. Cheers
