I do this as well, but there is a workflow problem to solve and that is: getting PRs merged when they need to be to continue working.
It's not a simple problem to solve, we can't all just jump because someone finished some work after all. But if the PRs are OK to rubber stamp, and merge, and they're safely behind a feature flag, then it could just be as simple as letting the submitter merge without the need for an extra review. That can of course be contentious, but then we can ask "why not?" and figure out what non-human gateways need to be added to help make it possible etc.
I'm finding myself increasingly interested in understanding what friction can be removed from the software review, merge and release process, without sacrificing safe, well tested, understandable code that follows good standards.
The question is, why are you not just merging them into main as you go? It's a bit of a smell when you "need" to merge branches into branches. It shows a lack of safety and ease in deployments, which is the real problem to solve IMO.
Stacked PR’s… don’t do that though? They’re just PR’s. You can merge just the first one in the stack, and now it’s not “all or nothing”. Reading the docs, I don’t see a way to signal that the PR’s must all merge together.
Because the most natural way of saying “these changes need to land atomically” is called a branch, and landing it atomically is called a “merge”. But I guess GH’s UI sucks for reviewing large changes, so we’re stuck having to make each change independently mergeable and pass tests (likely disabling dead-code lints, etc) just to work around this limitation. Sigh.
At least when I actually do want changes to be mergeable in a stack, I now have a better UX for having folks review them.
I mean, unless you work at an organisation that deals with a specific religion, I would say that they're all NSFW, as there's no reason to be using them at work, and they're bound to cause controvosy at some point.
Given the level of NSFW material in some of them (sex, violence, etc), I think it's not surprising they're getting labelled as such, even without the link to a religion.
It really depends on the decision, what was done, and the overall impact. If the decision is to migrate to microservices, a year in it may be reviewed and decided that the work has been far more than anticipated, and is too much for EVERYTHING to be migrated, and the decision changed.
Or it might be an architectural decision to change the hierarchy of some organisational structure. Again, it could be the correct call for the time, but as things evolve over a year, it may not be sufficiant a year later.
A year isn't a bad time to review, and if the decision is just a "yeah, duh, of course we'll continue", then it's a really quick conversation, but at least you're thinking about things.
You can review - but by the time you really know it is too late. If things are going really bad after one year then start over. However often things that will go well long term are having "growing pains" at 1 year and so "staying the course" despite the pain might be the right decision. Until you have a microservices architecture you don't know the pros/cons of it for your system - you can get insight from others, but their system will be different and so will have different problems.
Your org chart should be tweaked every year - as should your architecture. However major changes should not happen often - if at all.
A year is and is not a long time, so it depends on how seasonal the prosu is. New years celebration decorations are at one end of the spectrum, but it turns out a lot of things have a seasonality to them as well.
As another data point, I run a k8s cluster on Hetzner (mainly for my own experience, as I'd rather learn on my pet projects vs production), and haven't had any Hetzner related issues with it.
So Hetzner is OK for the overly complex as well, if you wish to do so.
You don't need AI if that's all you're using it for. In fact, IDEs have been doing a fine job at that for years.
It feels right now, that much of the time, AI is a solution looking for a problem to solve.
I find it more useful to treat AI like an easier to search stack overflow. You can ask it to go find you an answer, and then elaborate when it's not the right one.
Or one or two devs in the F100 customers made an account using their work email so they could chuck some OSS prototype code somewhere, or test something out.
You should report sites that do that. We still enforce the GDPR, and it's illegal to force acceptance of cookies (excepting functional cookies) for any reason, including offering to remove them for money.
No we don't, and we never did. The whole "GDPR" thing is a sham - unfortunately this is the case in many countries, but especially so in the UK. The ICO is one of the most useless "regulators" I have ever dealt with, somehow even worse than telecoms regulators.
This isn't some sort of subtle and concealed breach of the GDPR that everyone puts effort into keeping quiet. It's blatant, obvious, and in the face of everyone who visits major news websites. If it was enforced, the practice would've quickly stopped.
It's about as subtle as committing murder on live TV. If you don't get arrested for that, it's clear that the law you've broken is not being enforced.
> You should report sites that do that
But let's hypothesize and see what it takes to actually do this:
As per the ICO's requirements, you must first contact the organization that has wronged you and give them time to address your concern.
They have 30 days to do respond, and could extend it potentially indefinitely by engaging in pointless arguments. They could also make technically flawed arguments in how they're not actually tracking you or collecting personal data, and those will successfully work because there's no technical expert on the ICO's side to review it and call bullshit. You need full-time admin staff to deal with these matters.
Assuming you finally get to a stage where you have grounds to make a complaint to the ICO, what are they going to do (if anything)? Well at best they will send a letter, which is not legally binding in any way and will promptly get ignored by the recipient, which is fine because the truth is, both sides are complicit and just want the matter to go away - whether the underlying problem is solved or not is not their concern.
In practice, even if the ICO wanted to act (they don't - don't bite the hand that feeds), what would they do? This isn't a single, small offender, this is the entire newspaper industry. They not only have a lot of lobbying power but outright control the narrative. They know it, and that's why they have no fear putting evidence of their GDPR breach on their homepages.
Are you ready to hire a full-time admin team to do this (and end up absolutely nowhere, except maybe collecting evidence of this "regulator"'s uselessness)?
--
GDPR enforcement in the UK (and sadly in a lot of other countries) is and will remain a sham until the issue becomes politically important. The regulator on its own, even with the best of skill and intentions will not succeed in this battle. The only way I can potentially see this changing is if we see continuous and recurrent data breaches of politician's personal data and dirty laundry, but even then the likeliest solution is a two-tier system where politicians are allowed to have privacy while everyone else doesn't.
The EU isn't even a continent. It's a trade/political block, making up a part of a continent. And the part of the EU pushing back is generally just the European Parliament, not the whole organisation.
It's not a simple problem to solve, we can't all just jump because someone finished some work after all. But if the PRs are OK to rubber stamp, and merge, and they're safely behind a feature flag, then it could just be as simple as letting the submitter merge without the need for an extra review. That can of course be contentious, but then we can ask "why not?" and figure out what non-human gateways need to be added to help make it possible etc.
I'm finding myself increasingly interested in understanding what friction can be removed from the software review, merge and release process, without sacrificing safe, well tested, understandable code that follows good standards.
reply