I agree. Have always felt that USDS/18F are best in class examples of tech innovation being brought to perhaps slightly tech-backwards areas of government, and doing the interpersonal work to bring other agencies along as well.
The UK’s Government Digital Service is similar. They’ve got some good examples of doing unglamorous but impactful work -e.g. replacing dozens of different payment processing systems with one quality one, the same thing for sending physical letters, etc.
I’m a Fedora packager (not for this package). Like many others I have an unrelated day job.
If there’s an upstream complaint I might get to it this weekend, maybe next. If I’m busy for a few weeks that doesn’t make me stupid.
Have had my share of “discussions” with upstream who want the latest version packaged when this might not be completely in line with our guidelines. Not an uncommon issue.
Yeah it’s not fair to expect volunteers to show up on weekdays, I agree with you.
But equally, I don’t think it’s fair that packagers want to have it both ways. Packagers want to make subtle, possibly breaking changes to software they didn’t author. The end users feel the pain and complain to the author. The author has no control over the situation, and they’re feeling the pain during the working week.
So the packager has been instrumental in creating the problem with the patch, and when requested to do something about it, turns around and says “buddy I do this for free, I’ll get to it over the weekend, maybe.” Sure, but the author is feeling the pain right now.
Again, it’s nice that you’re volunteering your time for others. But it would be good if you acknowledged that the costs of packaging aren’t borne entirely by packagers. Authors bear part of the cost when they get blamed for broken software.
Sometimes changes are required to meet packaging guidelines, sometimes you can get exemptions. Of course users often don’t realise who’s done what.
I suppose my advice to upstream would be to direct the end user to the Fedora bug tracker, where the bug can land in my queue. Or advise the user to install from a different source.
The upstream that I’ve dealt with have been kind enough to lodge a bug themselves on the package I look after, which is also an option, and much appreciated.
> I suppose my advice to upstream would be to direct the end user to the Fedora bug tracker, where the bug can land in my queue. Or advise the user to install from a different source.
How is upstream supposed to make this happen when distro maintainers not only don't mark the package as modified by them, but also silently change the flatpak configuration so that installing packages from flatpak in the way that would normally install a clean upstream build doesn't do so?
The adverb correctly identifies that it’s more complicated than that.
The fantasy that “biological reality” is anything other than substantially more complicated and messy than a neat dichotomy with perfect alignment across sex characteristics and gender is both wrong and obviously so.
Nothing in medicine or biology is so simple. There’s always a way for the human organism to be more complicated. It keeps me very busy and in a job.
One of the core arguments is that DockerHub is the default for Docker. The article shows that the URL for dockerhub is baked into Docker and is used when no registry is specified.
(It’s also pretty decent. My usual go to for stuff I can’t justify spinning up an Adobe VM for…)
reply