Debian has been doing this for decades, yes, but it is largely a volunteer effort, and it's become a meme how slow Debian is to release things.
I've long desired this approach (backporting security fixes) to be commercialized instead of the always-up-to-date-even-if-incompatible push, and on top of Red Hat, Suse, Canonical (with LTS), nobody has been doing it for product teams until recently (Chainguard seems to be doing this).
But, if you ignore speed, you also fail: others will build less secure products and conquer the market, and your product has no future.
The real engineering trick is to be fast and build new things, which is why we need supply chain commoditized stewards (for a fee) that will solve this problem for you and others at scale!
I wonder if this has actually been used for backing up in real use cases (think how LVM or ZFS do snapshotting)?
I.e. an advanced compressor could abuse the zip file format to share base data for files which only incrementally change (get appended to, for instance).
Since firmware is supposed to be accessible to users worldwide, making it easier to get it is good.
But how is an open, read-only S3 bucket worse than a read-only HTTPS site hosting exactly the same data?
The only thing I can see is that it is much easier to make it writeable by accident (for HTTPS web site or API, you need quite some implementation effort).
Invite engineers to solve it in a way that makes it cheap for them.
Most shops I've been at prefix their branch names with ticket numbers ("bug-X-" or "TCKT-Y-"), and then it's trivial to reference it back. Some will write scripts on top, which gets them even more motivated to solve your problem (and might add links into the tracking tools too, move the ticket to "In Review" when the PR is up, close it after it's merged...).
But if nobody writes them, they don't have the habit of reading them either.
However, also make sure your PR descriptions are not "substantial" in the "there is a lot of it" sense, but only "substantial" in the "everything of substance is described, but not more" sense :)
But there are really two types of things you need to describe in a change request:
- What and why needs changing
- What the code does after the change
One should really try hard to keep the first one answered in a change request description, or comments in the tool for code reviews. Don't you love running into comments in the code of the type "// This performs better than sorting-after-load as the service offers built-in sorting." because someone originally did "load(); in_memory_sort()" and today the code only does a "load(order_by=X)" (I mean, duh).
The resulting code should only have comments that explain the why for the end-state code.
But yes, questions to explain something in the end-state should always trigger changes in the code: make code more self-explanatory!
What is the overall practice in the team? Does everybody write good descriptions and nobody reads them, or only a few of them write good descriptions and nobody reads them?
Because if it's the latter, there's your problem: even those who write good descriptions do not expect a change request to have one, so they don't bother looking.
By investing in quality on your job, your job will be easier and take less time. In software, you won't be called in to resolve that incident over the Thanksgiving weekend, and you won't be asked to debug why your system broke after someone committed 10k line diff without any review and without tests.
Be selfish! But be smart! On top of getting the best result for you, this gets the best result for the business too! And businesses know it, and even if they don't reward it proportionally, they do reward it with bonuses and seniority promotions.
I've long desired this approach (backporting security fixes) to be commercialized instead of the always-up-to-date-even-if-incompatible push, and on top of Red Hat, Suse, Canonical (with LTS), nobody has been doing it for product teams until recently (Chainguard seems to be doing this).
But, if you ignore speed, you also fail: others will build less secure products and conquer the market, and your product has no future.
The real engineering trick is to be fast and build new things, which is why we need supply chain commoditized stewards (for a fee) that will solve this problem for you and others at scale!
reply