5

Wielaard: Sourceware – GNU Toolchain Infrastructure roadmap

 1 year ago
source link: https://lwn.net/Articles/898655/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Wielaard: Sourceware – GNU Toolchain Infrastructure roadmap

[Posted June 22, 2022 by corbet]
Mark Wielaard writes about improvements at Sourceware, the site that holds the repository for many projects in the GNU toolchain and beyond.
Although email based git workflows are great for real patch discussions, they do not always make tracking the state of patches easy. Just like our other services, such as bugzilla, mailinglists and git repos, we like to provide zero maintenance infrastructure for tracking and automation of patches and testing. So we are trying to consolidate around a shared buildbot for (test) automation and patchwork for tracking the state of contributions.

(Log in to post comments)

Wielaard: Sourceware – GNU Toolchain Infrastructure roadmap

Posted Jun 22, 2022 22:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I've stated it before here (and elsewhere). Email-based workflows are fine except with the metadata tracking side. As a contributor, it is very hard to know:

- who has looked at your patch
- who plans to look at your patch
- once accepted, where it got merged to
- when that merge will make it into a release
- CI status

As a reviewer it is hard to know:

- is this the latest revision
- is the author working on changes out-of-band

*Some* kind of central depot is, IMO, essential for wrangling all the work that goes into a project (or subsystem for Linux since any single central depot would likely end up like LKML: too noisy to be generally useful by non-bots due to heavy filtering). Not everyone has their finely tuned email workflows or the time to set them up for one-off patch submissions.

I'm happy to see progress in this area. Some notes on the actual implementation here:

> And buildbot itself is automated, so whenever a change is made to add a new builder, or define a new container, the buildbot automatically reconfigures itself and the workers will start using the new container images starting with the next build.

This makes historical builds hard because "how was commit X tested" has some out-of-band information. I've come to storing Dockerfiles for CI in the repo itself and using dates for the image tags (macOS and Windows setups require some out-of-band info, but we minimize it to things like "Xcode Y.Z" and "VS 20XX toolchain Y.Z" as much as possible[1].

> The advantage over git hooks is that they run in the builder context, not in the context of the specific user that pushed a commit.

+100% I've come to distrust git hooks for "enforcement" of…anything because `git commit -n` exists. Verify things you care about centrally and report using your normal CI processes. Instead, hooks should be for workflow helpers (e.g., `git-lfs` data shuttling or syncing with a remote's version of your topic).

[1] Some packages are real PITA to manage and require global installation. So far, this has just been Windows for MPI and GPU driver installations.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK