pull down to refresh
101 sats \ 1 reply \ @random_ 19 Jul 2022 \ on: Who wants to take over the Lightning Shell? bitcoin
What is the update process like?
The time commitment to keeping it updated?
Very good questions.
It's hard for me to answer because of two reasons:
- I've always kept adding more features as well, I never thought about the minimum required time to keep it updated.
- It's been a while, so probably some stuff might break now. The more often the updates, the less issues.
That being said, the process is quite simple. It's just one Dockerfile (a template actually) that builds for two separate Debian versions - bullseye and buster (to be used on Citadel and Umbrel) and two architectures.
There are constants for Bitcoin, LND and BoS versions, and the rest of the apps are git submodules that require being updated to the last tags.
These steps can probably be automated quite easily.
The actual builds for buster/bullseye (which basically means Umbrel/Citadel) and architectures (x64/arm64) are done by GitHub jobs on push, but I always prefer to do extra builds locally, because some errors always occur on updates, and I prefer to keep the git history clean and only push what kinda works. But I guess this is not a requirement if somebody else takes over. SO it could work without local builds in theory.
So, usually I do one build locally that I then push to an Umbrel and test, and I assume that if this works, it is very likely to also work on x64 Umbrel and Citadel...
This whole part could arguably be also automated, probably with simply adding some tests that would run as GitHub jobs after build on all platforms...
What can also be considered is dropping some apps that are not really relevant. I loved including some nice extra stuff like
csview or gping, because I thought they are at least remotely useful to a node operator, and they were a nice touch, but of course - the more you add, the more trouble you'll have. If the future releases would be limited to just the Lightning stuff, complexity of updates would be certainly lower.I guess ultimately it would be nice to just find somebody that either 1) is a node operator and wants to do this out of passion OR 2) has another interest in doing this (for example selling a node solution and thus having an indirect benefit from this).
Of course everything could be simplified and reduced to the bare minimum, plus with some extra automation the time required would decrease. But it would also be nice to have somebody that actually loves this and wants to take it further - not from pure altruism, but either for learning or for some other (indirect) benefit. So that person would give more than the bare minimum required to update the apps to this.
reply