Skip to main content

Bluefin Server Alpha 2

· 4 min read
Project Bluefin
Automation & Factory

Alright, here it is, Bluefin Server, this one actually boots. This is the base of the Bluefin Factory, the thing you'll build your homelab on. And in turn, your desktops or whatever you want. Kubernetes for the home.

Bluefin Server

An FSDK-based, image-based Linux server OS.**

To celebrate this milestone, enjoy the latest video, with some fresh lore!

Bluefin Server targets the same use-case space as Flatcar Container Linux, Kairos, Fedora CoreOS, and Talos, but is built from scratch with BuildStream 2 from freedesktop-sdk (FSDK 26.08) components and uutils coreutils.

It is designed to be installed and then managed entirely through the Kubestellar GUI. I'll be releasing point releases quickly over the next few days. After the install it will give you a web address, then you go to it on your computer. Then that's it, your perfect home server.

Except the dashboards are empty. The more people we have making these the better, including a ZFS one! This variant will have ZFS support so now's the time to jump onboard!

It is DDI first: the OS payload is a compressed XFS DDI filesystem image that is deployed by an offline, systemd-native installer.

Release status: Alpha

Bluefin Server is currently in Alpha:

  • Milestone status: Phase A (reproducible build path, uutils, k0s sysext, graph validation) is complete. Phase B (automated boot verification on lab cluster) is in progress.
  • systemd-sysupdate should work, we're about to find out! configurations.
  • Readiness roadmap: Track completed criteria and remaining gates toward 1.0 in docs/MVP_1_0_READINESS.md.

How this works

  • A/B root rollback — an MVP 1.0 gate: 50-root.transfer names root-a and root-b; the installer currently creates only root-a.
  • DDI-first delivery — the installer embeds the OS payload as a data partition; no network is required at install time. This is basically Linux systemd style.
  • Minimal, distroless OS image — no shell in the running rootfs by default IS what we are shooting for. We'll probably fail at this lol.
  • systemd-native installersystemd-sysinstall provides the interactive terminal UI and systemd-repart handles partitioning and block-copy DDI placement. Finally distro installers can all go die!
  • Optional k0s as a systemd-sysext so the base image stays distroless. We started with k3s but I want to see how this one goes, stripped down for the home.

SSH ON: SSH is enabled for cluster boot tests and remote debugging. It is scheduled for removal once diagnostics move to serial logs or a guest agent. See docs/skills/factory-integration.md.

Quick start

Bare metal sorely needed! However this runs on any Linux, feel free to fire up a VM and start designing that dashboard! Once we get home assistant and all the goodies it'll be amazing! Thanks for checking it out!

You need only podman and just. BuildStream runs inside the FSDK bst2 container, so BuildStream is not installed locally.

just validate # resolve the element graph
just show-me-the-future # end-to-end QEMU installer smoke test

See AGENTS.md for the full build command matrix, hard rules, and agent skill routing.

Contributing

See CONTRIBUTING.md for the contributor checklist, Conventional Commit rules, and docs/skills/index.md for task-specific guidance.

I Dreamed of Linux Laptops for My Family

· 9 min read
Benjamin Sherman
Bluefin Contributor

Original post

A belated happy five years to Universal Blue, and how wanting laptops my family could actually live with turned me into an open source maintainer.

This is my personal site. Opinions here are my own and don't necessarily reflect those of Red Hat.

Maybe you saw that Universal Blue recently celebrated its five-year anniversary. Aurora, Bazzite, and Bluefin (the OG) all marked it with posts of their own. I’m thankful to be a part of the team that’s done such great work. I’m usually content to just get things done in the background, but it’s high time I share some of my thoughts about this project and organization we call Universal Blue.

When Jorge Castro made that initial commit five years ago, he was doing different things than we do today. He was running Fedora Silverblue or openSUSE MicroOS, using various scripts to shape the installation into his dream. It was a beginning.

I was in a different, but similar place. I could see the day approaching when my kids were going to need laptops for school, and they already wanted to do more gaming. I didn’t love managing Windows even for myself and didn’t want to manage multiple installs, but multiple Linux installs weren’t much more exciting. I was experimenting to find a solution to make supporting my family’s laptops seem less like sysadmin work, to find something that would “just work” instead.

My GitHub and private Git server are littered with repos full of old dotfiles, configs, Ansible playbooks and shell scripts. I was determined to pre-configure and automate all the post-install Linux things. For me, this “perfect Linux laptop” idea was brewing in 2021. That’s probably when I started to get a solid base of Ansible to manage my family’s Linux systems.

Though I’ve consistently been using Linux on the server for 30 years, desktop use has been more intermittent. “The Year of the Linux Desktop” is almost a perennial joke, and laptops almost always meant more pain than a typical desktop PC. It’s been decades since I bought into the religious wars of macOS versus Windows versus Linux versus BSD. At some point, pragmatism set in. I don’t really care which OS you’re running, but maintaining a fleet of laptops for your family is still a pain, except perhaps if they are all Chromebooks.

In November 2022, I stumbled across a blog post and video by Jorge. He’d been writing (and talking) about immutable Linux OSes, and at that moment he was comparing Fedora Silverblue and openSUSE’s MicroOS. MicroOS caught my attention as something I might use to make my family’s laptops a little bit more reliable. It promised something like ChromeOS that could still function as a normal system. I found it intriguing, but there were enough rough edges that I just couldn’t switch off the Ansible-customized Ubuntu which had become the in-home standard.

In December 2022, Jorge posted something magical. Fedora had released an experimental feature for Silverblue and Kinoite: container-native rpm-ostree. It meant we could have a custom built operating system image, but built like any other Docker image. I’d been living and breathing Docker images. I’d been running Kubernetes at home. I’d packaged applications in Docker images for work and home. The promise of pre-built application images, running the same thing everywhere, was now available as a custom operating system! I could bake in customizations for my family, fixes for all the quirks that normally I had to fix after an installation, or whatever I wanted. Maybe most importantly, all of the package and upgrade conflicts which inevitably occurred for any package management system were no longer an issue.

Quote

That whole class of problem would happen in CI, not on my laptop, certainly not on my wife’s or kids’ laptop!

And NVIDIA, oh, NVIDIA: the greatest love/hate of any Linux user who’d chosen to use it. Powerful and wonderful when it works, but often a pain to get going: NVIDIA would get the same treatment.

Fun fact, I’d used both Fedora Silverblue and CoreOS before, but I found them too restrictive without a better way to customize the defaults to have a better overall user experience. It’s kind of crazy that this turned around so quickly once I could participate in building the OS image itself. Container-native truly opened the door wide for new contribution in this space. It certainly did for me!

This is where I stopped watching what Jorge was doing from afar and got involved.

The ublue-os GitHub org and a Discord server had both been created. I joined the chat and saw them working on a pre-built NVIDIA kmod. I had some of my own custom images going, but I jumped in to help with that NVIDIA kmod; I had a vested interest in making it work. My first official contribution was on February 20, 2023. It wasn’t much, but Universal Blue was (and still is) a welcoming community, and I quickly became involved in more and more code reviews and code contributions. Not even a month later, I’d forked Kyle Gospodnetich’s serverblue repo into uCore, with his blessing of course. By then Kyle was fully invested in Bazzite!

The rest, as they say, is history! And frankly, most of the history is public record because all of our commits, issues, PRs and discussions are out in the open. It’s Open Source Software, after all. I found a passion for participating in the shared effort of building and maintaining our various Universal Blue projects; I stuck with it.

Quote

One day I looked up and realized, “oh, I’m a maintainer.”

Achieving that “status” was never a goal; rather, it was a natural progression. uCore became my primary Universal Blue project, and I’m practically its sole maintainer, though I’m also a core maintainer across all of Universal Blue, and a user of most of it. Working in the server space certainly matches my traditional interests, so I’m glad I can assist with the desktop projects but don’t need to carry that load alone.

Bluefin and Bazzite fulfilled the dream of Linux laptops that “just work.” Ansible ceased to be used for desktop/laptop management as the prebuilt images (bOS, my lightly personalized version of Universal Blue images) became the new home standard. My boys got Dell laptops with NVIDIA cards which enabled some 3D gaming as well as school, and maintenance was minimal, since those failures now occur in CI and never make it to the laptops themselves. My wife and daughter got a matching pair of HP laptops with AMD integrated graphics, better battery life and still some light gaming ability.

Quote

These systems just keep updating.

Are there occasional hiccups? Yes. Is it massively easier to maintain than before, when every other update seemed to result in a broken NVIDIA kmod or some other issue? 100%! I confess the boys argued their way into Windows specifically to play a game which still doesn’t work on Linux with Proton, but they miss the Linux desktop and I think I’ll win them back soon.

There is another important thing. I want to say “thank you” to Jorge and Kyle. Each had their own dreams… Kyle’s vision was to bring the “just works” gaming experience of the Steam Deck to any desktop or handheld, while Jorge pushed for the “just works” experience of a Chromebook but with more power and flexibility. Kyle, Jorge and I worked and gamed together, and Kyle would sometimes join me and my boys for gaming sessions. I wasn’t always sure how to relate to Jorge’s ambitious goals, but he challenged me to think bigger. Beyond these two, a whole group of people came together as friends and teammates to support each other personally and technically as we built the various Universal Blue projects.

Quote

This team has brought dreams to life.

One of those dreams has been to get people jobs! Most of us did this work outside our day jobs. Eventually some folks set up sponsorship via GitHub, etc, and that’s been awesome to help offset the costs of development, but day jobs pay the bills. The community and network Jorge built here has been excellent in that regard. Contributors to Universal Blue at different career stages have found their way into new opportunities at several different software companies. I’m one of them. My fairly recent start at Red Hat is a great example. My previous years of experience were crucial, but learning specific technologies and Open Source methodologies with Universal Blue provided a direct path to what Red Hat needed. So when I say I’m thankful for this project, and for the opportunity to participate, I mean it. My Universal Blue experience had already been personally and technically rewarding, but finding a job in Open Source through this project experience was next level!

Thank you to everyone who has contributed to a Universal Blue project, however big or small! Thank you for all the users! This has been a great adventure, and in the best possible way, I don’t see an end in sight.

Announcing mcp.projectbluefin.io

· 2 min read
Jorge O. Castro
Director of Dinosaurs

Model Context Protocol (MCP) is an open protocol for LLMs and agents to talk to each other. We're now serving the Project Bluefin organization knowledge base and live factory state at https://mcp.projectbluefin.io/mcp.

Right now hive.projectbluefin.io exposes an API that has things that are useful for agents. We use it to dole out work to volunteers and to get review tasks. This is what's letting us scale out in ways we haven't been able to before. Hive has a nice Knowledge Base that it exposes, so this initial cut is to search that knowledge. This is mostly useful to connect whatever agent you use to our stuff and get context for your agent. So if you want to do Bluefin things you just add this. I've updated the Agentic Contributor Guide, note that our hive API endpoints are published, so if you're building a deep integration it probably makes sense to work with the Hive API directly. Feedback and usage notes welcome!

Endpoint Details

  • URL: https://mcp.projectbluefin.io/mcp
  • Transport: Streamable HTTP / Server-Sent Events (SSE)
  • Authentication: None (public, read-only)
  • Health Check: https://mcp.projectbluefin.io/health

Available Tools

Here's what's exposed:

ToolDescriptionParameters
search_knowledgeSearch Project Bluefin knowledge base: engineering patterns, test coverage gaps, CI conventions, and repo findings across projectbluefin/*.query (string, required)
limit (integer 1–25, default 10)
get_factory_statusLive factory status from Hive: hub health, active contributors, actionable items, per-tier limits.None
get_work_queueLive work queue and triage state from Hive: issues ready to implement and triage grouping.limit (integer 1–25, default 10)
get_index_statusOperational health, record count, and timestamp of the published knowledge index.None
get_quickstartOnboarding checklists (first-pr, run-tests, factory-gates, branch-rules).topic (enum, required)
get_repository_mapHigh-level component map, entrypoints, and branch targets for bluefin, bluefin-lts, common, dakota, documentation.repo (enum, required)

Archaeopteryx August 2026

· 63 min read
Project Bluefin
Automation & Factory
Completed work
258
24 planned • 234 opportunistic
Contributors
16
0 first-time contributors

Activity

Completed work across the configured factory portfolio.

Daily merge calendar

Daily merged pull requests

541merged pull requests
Source: GitHub GraphQL · August 2026 UTC (2026-08-01 to 2026-08-31)
Show the numbers
Daily merged pull requests data for August 2026 UTC (2026-08-01 to 2026-08-31)
LabelMerged pull requests
2026-08-0138
2026-08-0220
2026-08-0330
2026-08-0414
2026-08-0512
2026-08-0610
2026-08-07117
2026-08-0820
2026-08-0954
2026-08-108
2026-08-113
2026-08-125
2026-08-1310
2026-08-145
2026-08-1515
2026-08-1611
2026-08-177
2026-08-188
2026-08-195
2026-08-2014
2026-08-2121
2026-08-2217
2026-08-238
2026-08-2419
2026-08-257
2026-08-2614
2026-08-274
2026-08-2811
2026-08-2910
2026-08-3022
2026-08-312

Repository comparison

Merged pull requests by repository

541merged pull requests
Source: GitHub GraphQL · August 2026 UTC (2026-08-01 to 2026-08-31)
Show the numbers
Merged pull requests by repository data for August 2026 UTC (2026-08-01 to 2026-08-31)
LabelMerged pull requests
projectbluefin/actions44
projectbluefin/bluefin155
projectbluefin/bluefin-lts38
projectbluefin/bonedigger3
projectbluefin/common50
projectbluefin/dakota92
projectbluefin/documentation18
projectbluefin/finpilot49
projectbluefin/iso1
projectbluefin/server4
projectbluefin/testsuite67
projectbluefin/utah6
projectbluefin/utah-packages14

Category distribution

Merged pull requests by label

435label assignments
Source: GitHub GraphQL · August 2026 UTC (2026-08-01 to 2026-08-31)
Show the numbers
Merged pull requests by label data for August 2026 UTC (2026-08-01 to 2026-08-31)
LabelLabel assignments
1-triage3
3-clanker-queue41
4-review38
agent/contributor2
automerge52
chore/deps52
cli/copilot2
contributor/castrojo2
dependencies2
hold13
javascript2
kde9
lgtm23
needs-human1
pr/needs-review67
quality3
release/ready63
renovate/high-risk16
renovate/low-risk3
runner9
security6
size:M1
size:S2
size:XL1
size:XS19
testing3

Stable portfolio

  • projectbluefin/bluefin
  • projectbluefin/bluefin-lts
  • projectbluefin/dakota
  • projectbluefin/testsuite
  • projectbluefin/server
  • projectbluefin/actions
  • projectbluefin/bonedigger
  • projectbluefin/aurorafin-shared
  • projectbluefin/common
  • projectbluefin/documentation
  • projectbluefin/branding
  • projectbluefin/iso
  • projectbluefin/finpilot

Experimental portfolio

  • projectbluefin/utah
  • projectbluefin/utah-packages

Delivery

Publishing-lane outcomes, cadence, duration, and release events.

Factory Publishing Lanes

Bluefin Testing
projectbluefin/bluefin
! 0%
0Passed
3Failed
65mMedian Run

Pending runs: 5

Run History
0Passed
0Failed
Median Run

Pending runs: 30

Run History
71Passed
2Failed
39mMedian Run

Pending runs: 12

Run History

Cadence and duration trend

Publishing-lane cadence

123publish runs
Source: GitHub Actions · August 2026 UTC (2026-08-01 to 2026-08-31)
Show the numbers
Publishing-lane cadence data for August 2026 UTC (2026-08-01 to 2026-08-31)
LabelBluefin TestingBluefin LTSDakota
2026-08-01000
2026-08-02000
2026-08-03000
2026-08-04000
2026-08-05000
2026-08-06000
2026-08-07000
2026-08-08000
2026-08-09000
2026-08-10000
2026-08-11000
2026-08-12000
2026-08-13000
2026-08-14000
2026-08-15000
2026-08-16000
2026-08-17000
2026-08-18000
2026-08-19000
2026-08-20000
2026-08-21010
2026-08-22010
2026-08-23010
2026-08-24603
2026-08-25004
2026-08-26107
2026-08-27009
2026-08-280735
2026-08-290016
2026-08-301117
2026-08-31094

Release-event timeline

Release events

13release events
Source: GitHub Releases API · August 2026 UTC (2026-08-01 to 2026-08-31)
Show the numbers
Release events data for August 2026 UTC (2026-08-01 to 2026-08-31)
LabelRelease events
2026-08-071
2026-08-061
2026-08-051
2026-08-041
2026-08-031
2026-08-021
2026-08-011
2026-08-311
2026-08-281
2026-08-241
2026-08-211
2026-08-191
2026-08-151

Participation

Human and automated contributions with current contributors.

Human and automation activity

Human and automation activity

541pull requests
Source: GitHub GraphQL · August 2026 UTC (2026-08-01 to 2026-08-31)
Show the numbers
Human and automation activity data for August 2026 UTC (2026-08-01 to 2026-08-31)
LabelHumanAutomation
Report period258283

Ecosystem context

Public ecosystem measures labelled with their native source windows.

Countme trend

Countme active systems

3920estimated weekly active systems
Source: Countme · Through 2026-07-27
Show the numbers
Countme active systems data for Through 2026-07-27
LabelActive systems
week-13561
week-23672
week-33606
week-43712
week-53780
week-63667
week-73584
week-83678
week-94195
week-103920

Homebrew trend

Homebrew tap additions

14package additions
Source: Homebrew taps · August 2026 UTC (2026-08-01 to 2026-08-31)
Show the numbers
Homebrew tap additions data for August 2026 UTC (2026-08-01 to 2026-08-31)
LabelAdditions
Production tap2
Experimental tap12

Flathub trend

Flathub trendData unavailable: Flathub statistics could not be read.

Release details remain on the canonical /changelogs surface.

Completed work

Dakota (GNOME OS Prototype)

Contributors

Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Sources

  • github-activity: available (2026-08-01 to 2026-08-31): source
  • github-lanes: available (2026-08-01 to 2026-08-31): source
  • github-releases: available (2026-08-01 to 2026-08-31): source
  • github-releases: available (2026-08-01 to 2026-08-31): source
  • github-releases: available (2026-08-01 to 2026-08-31): source
  • github-releases: available (2026-08-01 to 2026-08-31): source
  • github-releases: available (2026-08-01 to 2026-08-31): source
  • countme: available (2026-08-01 to 2026-08-31): source
  • homebrew: available (2026-08-01 to 2026-08-31): source
  • flathub: unavailable — Flathub statistics could not be read. (2026-08-01 to 2026-08-31): source

Reaffirming our Commitment to Upstream Kernel Development

· One min read
Jorge O. Castro
Director of Dinosaurs

Earlier this month Ahmed Adan and the rest of the Dakota team worked to bring the Open Gaming Collective kernel as an option for Bluefin's new "Gaming Mode". These kernels are explicitly designed to ship greg k-h's kernel and only ship patches that have a path upstream.

Here's some context:

Bluefin Gaming Mode and Dakota Alpha 5

· 4 min read
Jorge O. Castro
Director of Dinosaurs

Guardians ... a new Dakota arrives, likely our last before beta. @ahmedadan brings us an example of the power we can wield with BuildStream and The Final Shape. (Ask him about his COSMIC image!)

The builder is back in business and we now have enough institutional knowledge to make getting a new one and swapping it in easier. Improvements in the tooling in general has helped. And my homelab is doing from-source builds in 8 minutes, that's 4 minutes faster than assembling RPMs. We intend to make it trivial for anyone to deploy these on any modern infra. Buildstream and Kubernetes is a beautiful thing.

The world has changed! Here's the good stuff.

What it comes with

First let's get the versioning out of the way. Since we're based on freedesktop-sdk project we'll use their version. In this case, 25.08.11. The 11th release of the August 2025 major update. 26.08 is our next update. Yes, that's next month. :) Bluefin will remain versionless and tested as a whole, you'll just switch aggressiveness with game mode if you want:

  • Kernel: 7.0.11
  • Game Mode Kernel: 7.1.4-ogc1
  • GNOME Shell: 50.3
  • freedesktop-sdk: 25.08.11
  • bootc: 1.16.6
  • systemd: 260.2
  • Flatpak: 1.18.0
  • :testing GNOME 50 development builds
  • :stable Publishing daily if tests pass, moving to every other day for beta, weekly for GA
  • :next GNOME 51 rolling builds, currently busted.

We're helping out GNOME OS by shipping a new zswap configuration, based on their inprogress work upstream. Dakota uses zswap backed by a disk swapfile, rather than zram.

  • zswap.enabled=1 keeps recently swapped pages compressed in RAM, avoiding disk I/O when they are needed again.
  • zswap.compressor=zstd selects Zstandard: generally a good compression-ratio/CPU-speed balance.
  • zswap.max_pool_percent=20 caps the compressed RAM pool at 20% of installed memory.
  • zswap.shrinker_enabled=1 lets the kernel reclaim zswap memory under pressure by writing colder compressed pages to the backing swapfile.
  • vm.swappiness=100 makes the kernel treat reclaiming anonymous memory to swap as comparable in cost to reclaiming file cache. Since zswap absorbs the initial swap writes in RAM, this aims to preserve filesystem cache without immediately incurring disk latency.

The backing store is /var/swap/swapfile, created on demand at min(RAM / 2, 8 GiB) when the disk is large enough. Dakota explicitly disables GNOME OS's zram device, so it does not stack zram and zswap; The kernel arguments live in /usr/lib/bootc/kargs.d/20-zswap.toml, so bootc applies them on image switches and upgrades.

Feel free to give feedback on the swap stuff, it's an exciting area where we can hope to help out GNOME!

Open Gaming Collective

As part of our mission to improve the Linux desktop we're offering a "Game Mode" to Bluefin, which will pull in a bunch of stuff. It will be available in a checkbox in the control panel and is basically a lightweight Bazzite-lite built with BuildStream.

Yes, an OGC gaming kernel with aggressive updates but at least upgrades will work, lol. It will slay, so it is also aliased to dakota:btw. For the discerning raptor rider.

  • The kernel includes gaming-focused patches/features, including sched_ext and ntsync
  • Steam and its 32-bit compatibility libraries and controller udev rules, etc all built in - this is basically the Steam flatpak, you'll show up as "Freedesktop" in the Steam Charts
  • Gamescope and the Steam Big Picture gamescope session
  • GameMode, MangoHud, and vkBasalt for performance management, metrics, and post-processing.
  • InputPlumber, SDL controller database, and handheld/controller support. Note that we don't support handhelds but shrug it's all Linux.
  • All that extra Vulkan, SDL, audio, X11, USB, and input compatibility libraries for native games and stuff. Shout out to Kyle Gospo for the guidance!
  • First-boot Flathub installs for Lutris, Heroic, Bottles, ProtonPlus, Protontricks, and GOverlay.

And I'm sure I missed some.

How to Get It

There will be a GUI for this soon, in the meantime enjoy! You can't rebase to this from another image, if you're not on dakota already you need to reinstall.

ImageStreamCommand
GamingStablesudo bootc switch ghcr.io/projectbluefin/dakota-gaming:stable
GamingTestingsudo bootc switch ghcr.io/projectbluefin/dakota-gaming:testing
NVIDIA GamingStablesudo bootc switch ghcr.io/projectbluefin/dakota-nvidia-gaming:stable
NVIDIA GamingTestingsudo bootc switch ghcr.io/projectbluefin/dakota-nvidia-gaming:testing

ISO Downloads

Jovial July 2026

· 47 min read
Project Bluefin
Automation & Factory
Completed work
126
19 planned • 107 opportunistic
Contributors
11
0 first-time contributors

Activity

Completed work across the configured factory portfolio.

Daily merge calendar

Daily merged pull requests

553merged pull requests
Source: GitHub GraphQL · July 2026 UTC (2026-07-01 to 2026-07-31)
Show the numbers
Daily merged pull requests data for July 2026 UTC (2026-07-01 to 2026-07-31)
LabelMerged pull requests
2026-07-0126
2026-07-0213
2026-07-0312
2026-07-049
2026-07-058
2026-07-0614
2026-07-077
2026-07-0813
2026-07-098
2026-07-106
2026-07-1114
2026-07-129
2026-07-137
2026-07-1410
2026-07-154
2026-07-167
2026-07-176
2026-07-187
2026-07-1931
2026-07-2087
2026-07-2134
2026-07-2214
2026-07-2317
2026-07-2412
2026-07-2524
2026-07-2615
2026-07-2717
2026-07-2840
2026-07-2948
2026-07-3020
2026-07-3114

Repository comparison

Merged pull requests by repository

553merged pull requests
Source: GitHub GraphQL · July 2026 UTC (2026-07-01 to 2026-07-31)
Show the numbers
Merged pull requests by repository data for July 2026 UTC (2026-07-01 to 2026-07-31)
LabelMerged pull requests
projectbluefin/actions38
projectbluefin/bluefin166
projectbluefin/bluefin-lts52
projectbluefin/common39
projectbluefin/dakota71
projectbluefin/documentation18
projectbluefin/finpilot72
projectbluefin/iso2
projectbluefin/server3
projectbluefin/testsuite92

Category distribution

Merged pull requests by label

525label assignments
Source: GitHub GraphQL · July 2026 UTC (2026-07-01 to 2026-07-31)
Show the numbers
Merged pull requests by label data for July 2026 UTC (2026-07-01 to 2026-07-31)
LabelLabel assignments
4-review471
agent/contributor1
automerge6
chore/deps6
cli/copilot1
contributor/castrojo1
kde3
pr/needs-review11
release/ready10
runner3
size:XS12

Stable portfolio

  • projectbluefin/bluefin
  • projectbluefin/bluefin-lts
  • projectbluefin/dakota
  • projectbluefin/testsuite
  • projectbluefin/server
  • projectbluefin/actions
  • projectbluefin/bonedigger
  • projectbluefin/aurorafin-shared
  • projectbluefin/common
  • projectbluefin/documentation
  • projectbluefin/branding
  • projectbluefin/iso
  • projectbluefin/finpilot

Experimental portfolio

  • projectbluefin/utah
  • projectbluefin/utah-packages

Delivery

Publishing-lane outcomes, cadence, duration, and release events.

Factory Publishing Lanes

Bluefin Testing
projectbluefin/bluefin
△ 87%
13Passed
2Failed
44mMedian Run

Pending runs: 4

Run History
19Passed
11Failed
23mMedian Run

Pending runs: 6

Run History
14Passed
8Failed
61mMedian Run

Pending runs: 15

Run History

Cadence and duration trend

Publishing-lane cadence

92publish runs
Source: GitHub Actions · July 2026 UTC (2026-07-01 to 2026-07-31)
Show the numbers
Publishing-lane cadence data for July 2026 UTC (2026-07-01 to 2026-07-31)
LabelBluefin TestingBluefin LTSDakota
2026-07-01000
2026-07-02000
2026-07-03000
2026-07-04000
2026-07-05000
2026-07-06000
2026-07-07000
2026-07-08000
2026-07-09000
2026-07-10000
2026-07-11000
2026-07-12000
2026-07-13000
2026-07-14000
2026-07-15000
2026-07-16000
2026-07-17000
2026-07-18000
2026-07-19000
2026-07-20000
2026-07-21000
2026-07-22000
2026-07-23000
2026-07-24000
2026-07-25000
2026-07-260180
2026-07-27030
2026-07-28100
2026-07-2913616
2026-07-303612
2026-07-31239

Release-event timeline

Release events

50release events
Source: GitHub Releases API · July 2026 UTC (2026-07-01 to 2026-07-31)
Show the numbers
Release events data for July 2026 UTC (2026-07-01 to 2026-07-31)
LabelRelease events
2026-07-201
2026-07-191
2026-07-181
2026-07-171
2026-07-161
2026-07-151
2026-07-141
2026-07-131
2026-07-121
2026-07-111
2026-07-101
2026-07-091
2026-07-081
2026-07-071
2026-07-061
2026-07-051
2026-07-041
2026-07-031
2026-07-021
2026-07-011
2026-07-311
2026-07-301
2026-07-291
2026-07-281
2026-07-271
2026-07-261
2026-07-251
2026-07-241
2026-07-231
2026-07-221
2026-07-211
2026-07-201
2026-07-191
2026-07-181
2026-07-171
2026-07-161
2026-07-151
2026-07-141
2026-07-131
2026-07-121
2026-07-111
2026-07-101
2026-07-091
2026-07-081
2026-07-071
2026-07-061
2026-07-311
2026-07-111
2026-07-201
2026-07-111

Participation

Human and automated contributions with current contributors.

Human and automation activity

Human and automation activity

553pull requests
Source: GitHub GraphQL · July 2026 UTC (2026-07-01 to 2026-07-31)
Show the numbers
Human and automation activity data for July 2026 UTC (2026-07-01 to 2026-07-31)
LabelHumanAutomation
Report period126427

Ecosystem context

Public ecosystem measures labelled with their native source windows.

Countme trend

Countme active systems

3920estimated weekly active systems
Source: Countme · Through 2026-07-27
Show the numbers
Countme active systems data for Through 2026-07-27
LabelActive systems
week-13561
week-23672
week-33606
week-43712
week-53780
week-63667
week-73584
week-83678
week-94195
week-103920

Homebrew trend

Homebrew tap additions

3package additions
Source: Homebrew taps · July 2026 UTC (2026-07-01 to 2026-07-31)
Show the numbers
Homebrew tap additions data for July 2026 UTC (2026-07-01 to 2026-07-31)
LabelAdditions
Production tap1
Experimental tap2

Flathub trend

Flathub trendData unavailable: Flathub statistics could not be read.

Release details remain on the canonical /changelogs surface.

Completed work

Dakota (GNOME OS Prototype)

Contributors

Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Sources

  • github-activity: available (2026-07-01 to 2026-07-31): source
  • github-lanes: available (2026-07-01 to 2026-07-31): source
  • github-releases: available (2026-07-01 to 2026-07-31): source
  • github-releases: available (2026-07-01 to 2026-07-31): source
  • github-releases: available (2026-07-01 to 2026-07-31): source
  • github-releases: available (2026-07-01 to 2026-07-31): source
  • github-releases: available (2026-07-01 to 2026-07-31): source
  • countme: available (2026-07-01 to 2026-07-31): source
  • homebrew: available (2026-07-01 to 2026-07-31): source
  • flathub: unavailable — Flathub statistics could not be read. (2026-07-01 to 2026-07-31): source