Great analysis / report. At times a bit repetitive, but that could be useful for people skimming or jumping or quoting as well.
Despite 91% of CTOs citing technical debt as their biggest challenge, it doesn’t make the top five priorities in any major CIO survey from 2022–2024.
Sad. Tragic.
I'm lucky to be in a good, small company with a good, reasonable customer, where I naturally had and grew into having the freedom and autonomy to decide on things. The customer sets priorities, but I set mine as well, and tackle what's appropriate or reasonable/acceptable. Both the customer and I have the same goals after all, and we both know it and collaborate.
Of course, that doesn't help me as a user when I use other software.
Reading made me think of the recent EU digital regulations. Requiring due diligence, security practices, and transparency. It's certainly a necessary and good step in the right direction to break away from the endless chase away from quality, diligence, and intransparency.
I understand the need for full detailed reasoning, but that legalese document is not approachable or accessible.
I wish they had at least given a plain language summary of the changes they intend to make. For full reasoning you could still refer to the whole document.
I guess I'll trust the EFF in their interpretation.
Numerous invalid patents have been granted in the past, and had to be challenged to be corrected.
These suggested changes are horrendous for a just or sustainable patent system.
There may be opportunities for change or efficiency gains, but blocking and evading challenges in various ways is not a good approach. It excessively favors patent trolls which act maliciously and damaging to other companies, the economy and society at large.
While I agree with the later (or middle?) points, maybe for different reasons or maybe I would have reasoned differently, I mostly disagree with the earlier points.
Any really important comments get lost in the noise
What kind of comments are they using?
When I leave comments on GitLab they're threads that get resolved explicitly. GitHub also uses resolvable threads. The assignee/creator goes through them one by one, and marks them as resolved when they feel they're done with them. Nothing gets lost like that.
I also make use of '⚠' to mark significant/blocking comments and bullet points. Other labels, like or similar to conventional comment prefixes, like "thought:" or "note:", can indicate other priorities and significance of comments.
Instead of leaving twenty comments, I’d suggest leaving a single comment explaining the stylistic change you’d like to make, and asking the engineer you’re reviewing to make the correct line-level changes themselves.
I kinda agree, but I often leave the comment on the/a code in question, and often add a code change suggestion to visualize/indicate what I mean. This comment may stand in and refer to all other occurrences of this kind of thing. It doesn't have to apply exclusively on those lines.
Otherwise you’re putting your colleagues in an awkward position. They can either accept all your comments to avoid conflict, adding needless time and setting you up as the de facto gatekeeper for all changes to the codebase, or they can push back and argue on each trivial point, which will take even more time. Code review is not the time for you to impose your personal taste on a colleague.
I make sure that my team has a common understanding of, and the comments adding sufficient context/pretext to make it clear, that code change suggestions and "I would have [because]" are usually or in general can be freely rejected, unless specified otherwise. Often, comments include information of how important or not changes are to me, in comments themselves, and/or comments summarizing a review iteration (with a set of comments). The comments can also serve as a spark for discussion about solutions and approaches, common goals or eventual goals of the changed code that may be targeted after the code changes currently under review.
Review with a “will this work” filter, not with a “is this exactly how I would have done it” filter
I wouldn't want to do it like that, specifically. It's a question of weighing risks and medium and long term maintainability vs delivery, work, changeset, and review complexity and delay. Rather than "will this work", I ask my self, "is this good enough [within context]".
Leave a small number of well-thought-out comments, instead of dashing off line comments as you go and ending up with a hundred of them
Maybe I've had too many juniors to get into this mindset. But I've definitely had numerous times where I did many comments on reviews, even again on successive iterations. Besides reviewing the code technically, the review can also serve as a form of communication, assimilation, and teaching (project an codebase at hand, work style, and other things).
It's good to talk about concerns, issues, and frustrations, as well as upsides of doing so and working like that. Retrospectives and personal talks or discussions can help with that. Apart from other discussion, planing, and support meetings, the review is the interface between people and a great way to communicate.
That goes directly against the open, transparent development model of the Linux Kernel.
When you're developing in the open, everything becomes "public relations".
When you're working for Heinz, is it a mustard bottle?
Did you not do code reviews? It's the main thing I would miss. Being able to comment in-line, and manage iterations, is very valuable to me.
Very interesting. A trove of experience and practical knowledge.
They were able to anticipate most of the loss scenarios in advance because they saw that logical arguments were not prevailing; when that happens, ""there's only one explanation and that's an alternative motive"". His ""number one recommendation"" is to ensure, even before the project gets started, that it has the right champion and backing inside the agency or organization; that is the real determiner for whether a project will succeed or fail.
Not very surprising, but still tragic and sad.
What are the chances of the parent also beginning with seven zeroes?
I suspected author or commit date manipulation. But the commits look entirely like normal commits. So it must be pure chance?
00000003dd63b4c5af111a31269ed8a18d0823fa0000000ae6a4e242e802c943f465373b70b07469Is ur an English word? Known meaning in English languages? I don't think so? I'm surprised they don't mention why they name it ur-languages.
In German, the word prefix ur means origin, stemming from the word Ursprung (origin). Which makes sense as origin-languages. And could have been named origin-languages, honestly.
Study, get a bachelors degree
That's not 6 months though
Gitlab will most likely use it as a big selling point once all the work has been done by externals with little to no cost to Gitlab.
I don't think so. It'd/'ll be a nice feature, and be listed as such. But it's not one of their primary selling points or marketing targets. Federation will be niche. Most useful in the FOSS space that pays little anyway.
AGPL release
Cloud page explicitly mentions and links Self-Hosting
k8s folder in repository
They seemingly intend to offer cloud hosting with SDK integration, while also allowing to setup your own Kubernetes cluster.
There's no sign of them maybe revoking open source. Quite the contrary.
My [own] projects don't get popular, so having issues enabled doesn't cause issues. :P