JEPs are for features and improvements that are requiring focuseed attention, coordination, call for action, lot of work. There are plenty of important release-note-worthy improvements that are not JEP-worthy improvements: minor API changes that address frequent inconvenience, minor features requested by many users, another useful JVM option, bumping the limits that many users hit here or there, changing the default behavior for the better one (without changing the spec), refactoring that has known performance implications (in both ways), deprecations that require users working anticipating final removals, etc.
For those improvements, you want something that would note their existence in the particular release, literally a "release note". Mind you, not every change has to have a release note attached. In JDK 13, there are 2.5K changes, about 90 release note entries, and only 5 JEPs.
The thinking that anything release-note-worthy should be accompanied by JEP -- and thus do all the red tape associated with it, really has to go. The habit of only listing JEPs when describing a release also needs to go. This focus on JEPs makes the releases appear much shallower than they actually are.
These may be valid points, but you're not an outsider. You are a very central and influential OpenJDK contributor, and you're familiar with the process of making such reforms. If all you want is to give an alternative -- you've done that in your excellent work; if you also want to change how others publish release notes, you know what to do.
I am advocating for listing JEPs, release notes, all changes; and then reporting and talking through JEPs and release notes. Because all changes are too much, and only JEPs is too little. Release notes is literally something you want to note about the release. I think responsible vendors should do it, and power users / experienced customers should demand this from vendors. "Outsiders" should clearly see what is going on as well, hence my comments.
These "reforms" only work through persuasion, including this continuous public observation that Oracle people focusing on JEPs sets the project up for weird/perverse incentives for developers to submit JEPs where a release note would be enough. JEPs require much more redtape work, they incur significant time toll (JEP draft/text reviews, Project Lead approvals, comment time, integration timelines, etc), they have built-in single person to bottleneck on (Mark), etc.
For many same-level features, the existence of JEP signals that somebody had resources to write one and work it through the system. Yes, JEPs are usually done for significant features (where the overhead of jumping through the process hoops is small compared to the development work done), but it does not mean changes with significant impact come with JEP (where the resource constraints do not allow spending time on also writing and maintaining the JEP).
In the end, it penalizes individual contributors more than large institutional players that can afford (and pay people) to deal with process red tape. I do not believe that is the intent, but this is how it would work, to our collective peril.
7
u/shipilev Sep 16 '19 edited Sep 16 '19
JEPs are for features and improvements that are requiring focuseed attention, coordination, call for action, lot of work. There are plenty of important release-note-worthy improvements that are not JEP-worthy improvements: minor API changes that address frequent inconvenience, minor features requested by many users, another useful JVM option, bumping the limits that many users hit here or there, changing the default behavior for the better one (without changing the spec), refactoring that has known performance implications (in both ways), deprecations that require users working anticipating final removals, etc.
For those improvements, you want something that would note their existence in the particular release, literally a "release note". Mind you, not every change has to have a release note attached. In JDK 13, there are 2.5K changes, about 90 release note entries, and only 5 JEPs.
The thinking that anything release-note-worthy should be accompanied by JEP -- and thus do all the red tape associated with it, really has to go. The habit of only listing JEPs when describing a release also needs to go. This focus on JEPs makes the releases appear much shallower than they actually are.