Aslında dediğim de onla aynı doğrultuda sanki, kişinin kendini bilmesi, kendi üzerinde neyin çalıştığını keşfetmesi, hangi “pitfall” lara düşebileceğini tahmin etmesi.

Başlama konusunda emin olamadım, “kervan yolda düzülür” demek bazen plan yapmaya üşenmek için bahane olabiliyor. Yerine göre, mesela beklemek yerine bazen bir şekilde başlamak daha efektif olabilir, ama plan yapmamak için başlamak genelde uzun vadede zarar gibi.

That's why I think we should only increase breaking change for this artifact in specific cases such as, backwards incompatible version dependency upgrades, package name changes for all etc.

At this point no developer cares if the major version increased in-between changes, it is not actionable.

For example service A removes an unused endpoint, it is registered as a breaking change but it is only breaking for service A, but it is a single jar, so the major version increases for everyone. Based on this, I'm pretty sure we made much more than 19 breaking changes.

The term "breaking-change" is loosely defined for this case. It is an internal protobuf monorepo that generates a single jar. We are doing breaking changes quite often as APIs evolve, but they shouldn't increase the major version necessarily.

One of our internal libraries is at v23.136.0

I think the way we do semantic versioning is totally useless at this point.

Final explanation from UMN: cse.umn.edu/cs/statement...

According to the apology letter, the research on stealthily introducing vulnerabilities was concluded last year and those commits were a product of a new research which aims to fix kernel security bugs. Also reverting all commits would result in losing valuable fixes.

Paper mentioned: raw.githubusercontent.com/QiushiWu/qiu...

Original patch that started the banning process,
lore.kernel.org/linux-nfs/20...

Apology letter from the authors,
lore.kernel.org/lkml/CAK8Kej...

Q&A:
www-users.cse.umn.edu/~kjlu/papers...

Looking at what the professor at UMN published in 2020,

"On the Feasibility of Stealthily Introducing
Vulnerabilities in Open-Source Software via
Hypocrite Commits"

This paper was the reason why Linux maintainers were so sceptical about the patch.

However another maintainer mentions he took a look at OP's patches and 3 of 4 are seemed to be adding bugs. This creates a lot of suspicion on OP's intentions and they immediately decide to revert all PR's coming from UMN (the university of the researchers) and ban them from any contribution.

However the OP claims those commits are auto-generated by some experimental tool and did not carry a bad intention. There is also some evidence that the same professor worked on static analysis tools.

> Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way.
>
> This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university...

Couple contributors quickly join, some argue there isn't a double-free bug and some say it should be fixed in a different way.

However a major kernel developer Greg KH answered,

It starts with a patch on the GSS-based authentication (auth_gss.c) used within the linux kernel's SunRPC implementation. SunRPC is developed by Sun Microsystems as a part of their NFS implementation.

That patch supposedly prevents a "double-free" bug.

I have just started reading abut A2A, from official documentation,

> We recommend that applications model A2A agents as MCP resources (represented by their AgentCard). The frameworks can then use A2A to communicate with their user, the remote agents, and other agents.

I am really confused.

"Indeed, for *most* of the users I tested this against, it worked very well"

I also wonder if we can measure the accuracy of this method numerically using this methodology. It should be fairly simple to get some numbers and show how good this method is!

Great work! Can you elaborate more on the visualization part, what are we looking at exactly? I also wonder how native / non-native speakers compare on those charts.

Block mekanizması App View'da yapıldığı için aslında PDS'e seni engellemiş insanların cevap atması ve başka viewlarda gözükmesi mümkün 😄.

Acaba blok'u kaldırırsan geçmişteki o yorumlar da gözükmeye başlıyor mu.