Setup.py for Forked Projects – Accepted Best Practices

This line is meant to pertain to derivative works which are maintained and shipped separately from the master. In such a case, you would need to keep these records (which is done automatically by source control)

What you have done however is not a derivative work. You have committed your changes and have been pulled back to the main branch. Your changes are now part of the original project.

Furthermore, using source control (a public repository) means you will always be complying with this requirement.

There is the issue of how each person may define "prominent". To developers, source control(/+issue tracker) is a prominent way of viewing changes, however if you are maintaining a derivative work, you may want to maintain a list of substantial changes in a non-technical format.

I am unfamiliar with the Greg Stein Python fork, so discount this comparison as speculative historical analogy if you wish. But this was exactly the historical experience of many infrastructure codebases moving from single- to multi-threaded implementations.

Essentially every Unix implementation I studied in the 1990s--AIX, DEC OSF/1, DG/UX, DYNIX, HP-UX, IRIX, Solaris, SVR4, and SVR4 MP--all went through exactly this kind of "we put in finer-grained locking--now it's slower!!" problem. The DBMSs I followed--DB2, Ingres, Informix, Oracle, and Sybase--they all went through it too.

I have heard "these changes won't slow us down when we're running single-threaded" a million times. It never works out that way. The simple act of conditionally checking "are we running multithreaded, or not?" adds real overhead, especially on highly-pipelined CPUs. Atomic operations and occasional spin-locks added to ensure the integrity of shared data structures have to be called quite often, and they're very slow. First-generation lock/synchronization primitives also were slow. Most implementation teams eventually add several classes of primitives, in various "strengths," depending on how much interlock protection was needed at various places. Then they realize where they initially slapped down locking primitives was not really the right place, so they had to profile, design around the bottlenecks found, and systematically roto-till. Some of these sticking points eventually got OS or hardware acceleration, but that whole evolution took 3-5 years, bare minimum. Meanwhile, the MP or MT versions were limping, performance-wise.

Otherwise-sophisticated development teams have argued that such slowdowns are basically a persistent, intractable fact of life. IBM e.g. refused to SMP-enable AIX for at least 5 years after the competition, adamant that single-threaded was just purely better. Sybase used some of the same arguments. The only reason some of the teams eventually came around was that single-thread performance could no longer be reasonably improved at a CPU level. They were forced to either go MP/MT or accept having an increasingly uncompetitive product.

Active concurrency is HARD. And it's deceptive. Everyone rushes into it thinking "this won't be so bad." Then they hit the quicksand, and have to plod through. I've seen this happen with at least a dozen name-brand, well-funded, smart teams. Generally it seemed to take at least five years after choosing to multi-thread to "get back to where they should be, performance-wise" with MP/MT products; most were still meaningfully improving MP/MT efficiency/scalability even ten years after making the shift.

So my speculation is that, absent GvR's endorsement and support, no one has taken on the long trudge for Python and its GIL. Even if they were to do so today, it'd be Python 4.x timeframe before you'd say "Wow! We're really over the MT hump!"

Perhaps there is some magic that separates Python and its runtime from all the other stateful infrastructure software--all the language runtimes, operating systems, transaction monitors, and database managers that have gone before. But if so, it's unique or nearly so. Everyone else removing a GIL-equivalent has taken five-plus years of hard, committed effort and investment to get from MT-not to MT-hot.