Hi! Multiple things happened, and long story short I'm starting back to get into Tow-Boot things in the short term.
One thing I wanted to do already, but hadn't had the time to deal with previously, was reducing the bus factor (of about exactly one). And well, it would have been nice if it had been done earlier.
So now one of the first thing I want to deal with is reducing that bus factor, and get to a place where things like updating and releasing can all happen without the involvement of any specific person. In other words, setting things up so ways to get involved are well-defined and known to make things easier to start contributing.
Note that I am not looking for any number of people. And there is no actual strong commitment.
I am mainly making things more transparent, and showing ways to start contributing. Really, a refined form of this should be part of CONTRIBUTING.md at some point.
There is no limit in time to when this applies either. I expect anyone who wants to help can at any point begin, and at any point stop helping and contributing.
There are a couple of ways individuals can do to help and contribute:
- Device maintainer (as tester)
- Device maintainer (as author)
- U-Boot maintenance
- Tow-Boot feature writer/maintainer
- Triaging and helping
- Nix expressions (tooling) writer/helper
- Overall "management" of the project
Some of you might already find themselves doing some of it already!
None of them are exclusive to each-others, and not a hierarchy either. As an example, one can work with the Nix tooling without being exactly familiar with the innards of U-Boot/Tow-Boot the implementation, while still knowing how to make it build for their device and verifying things.
Feel free to ask questions, preferably publicly, about contributing. If there are reasons to ask privately, you can do so too.
I split this into two distinct groups, as in the end they require a different skill set.
Testers are people that own the target devices, know how to, or know how to know how to recover from improbable bad builds temporarily inconveniencing their systems. They can verify things are working as expected.
Authors are those contributing fixes and new descriptions for builds for devices. Otherwise they generally should also own the devices, though it's possible that an author helps someone by writing and fixing things in the tooling for someone else who is testing.
I'm using this designation as the main work here would be ensuring continued updates and maintenance vis-à-vis mainline U-Boot.
The main things to do here is forward-porting the work, and when feasible, helping with upstreaming all that can.
This is separate from working on the features, and doing novel work with Tow-Boot, but just as important, if not more. There is less familiarity required with the U-Boot codebase, but more familiarity required with how to manage different feature sets across evolving codebases.
Knowing that continued updates and maintenance is done helps with reducing the burden on the feature writers.
Working on the specific non U-Boot features here is the key differentiator. This would require more familiarity with working in larger C programs, and authoring new features.
Like I hinted at in the previous section, this is different, even though there is likely to be a large cross-section here. I wanted to make the distinction so people who don't think they can manage writing new code, but know how to manage patches can still feel welcome.
Feature writers will obviously be there to handle larger issues when maintaining, forward-porting, or upstreaming when there is any need. (And really should be involved.)
This is just like it sounds: helping with triaging, and helping with support/questions.
This may actually be the hardest job in the lot, but also the more approachable one for those with less directly related development experience.
Familiarity with how things work sure helps, but even with only a superficial level of understanding help is appreciated. Someone that knows how to get the best help is definitely welcome. And at worst, you'll end-up learning!
This is a special one. I frontload the fact it's to help with Nix, since the tooling is pretty much exclusively built on some of the NixOS ecosystem technologies.
Since this project is part of the expected happy path for end-users on U-Boot-supported systems, I have made a separate announcement more targeted making it known that having people known to be able to help when needed is desired.
But the offer is not exclusive to Nix experts, nor even Nix users. While this project is not representative of NixOS (the distribution) usage, it may be an point of entry for someone that wants to know more and learn about Nix and how it can be applied for real world usages outside of NixOS. So make yourself known if that may be you!
This one is the only one not open to just anyone.
As I said, I am also looking to set things up so the whole project can continue moving forward without my personal involvement being required. This means starting to set things up so multiple people can prepare a release, and manage things (e.g. permissions in GitHub, and at some point managing "infra" like domain names and such).
So since this is the only job requiring trust, this is the only one where I will arbitrarily decide and judge about, at the beginning.
I'm thinking well-known contributors and members to other projects are the kind of people that can help out with this. Obviously, they need to be also involved with Tow-Boot at some level, to finish building-up trust.
If you're unsure whether you are or are not someone that would be trustworthy, do ask! (Privately is fine.)
While it sounds like a fun thing, really there is nothing much to do other than (I expect) rarely flipping options in the admin panel of the org, and early on "pushing the button" to make a release. Most of the release lifecycle is automated already.
No!
I absolutely still believe a project sharing the overall vision/goals is needed, and do want to continue with the exact things I was working on. And part of this is future-proofing the project.
As for me, it may take some time until I'm at the capacity I want to be at with this project, but am definitely working on making it so in the short term I'm picking back up and dusting things up. I wouldn't be asking for help if I wasn't intending to also be part of this!
Will I personally do less? At first yes. Later, we'll see. I'm sorry about the vagueness, but at the present I don't want to be entirely transparent about the situation. It's nothing alarming though.