To be precise and in keeping with your analogy, I don't want to ever get on a plane that was allowed into the air without a pre-flight check since statistics suggest in that case a Postmortem Review would be exactly what happens next! ;-) I might argue that
the same is true with the software I use. My question therefore breaks down to:
Sure, but while a pre-flight check is useful I think the mechanics (developers) are best equipped to do it and if it lands then no one need care about the nuts and bolts, but if there was an issue then the FAA needs to get involved and help figure out what part of the process broke and let the engine fan crack be missed.
* What does this give us that is functionally better than the current process?
Right now there is very clouded definition of what a 'release' is. I generally try and explain it as a big R-elease which is I see as the traditional Eclipse release (for Jetty: 9.x -> 9.y, 9 -> 10), goes through the process of creating docuware, scheduling release reviews, etc etc. Then there is the vast majority of little r-eleases that a project like Jetty does which are incremental releases on a minor version (9.4.x -> 9.4.y) which I think most closely resembles what I think Wayne calls a Service Release. These are supposed to just be fixing bugs and perhaps in the world of OSGI that makes sense but it is a poor definition for a project like Jetty. I think OSGI views a service release as 9.4.1.v20180101 -> 9.4.1.v20180202 which would make our users heads pop, we are dropping the v201080202 portion of our versioning for Jetty 10 because of the massive confusion within the community (we have had way too many people use M0 or RC0 releases because the v2018xx versions scared them into thinking they were snapshots and not official).
Anyway, Wayne said one thing that bothered me on the last call when he specifically called out these service releases as not requiring a formal release review. He said that they needed to be bugfixs only, specifically calling out not adding functionality. Careful review of Jetty point releases will show what we add apis as needed to expose what we consider improvements or functionality but that do not alter negatively what we consider our external api. To do otherwise would completely stall the project and halt any sort of incremental innovation we strive for. So we see the definition of 'Functionality' as different for Eclipse then for us and our users, the difference being one of granluarity. As an example, we see adding another session manager (like memcache) as a funtionality for Jetty, but not by Eclipse's definition. For Eclipse, I see replacing the entire session management implementation as a new Feature (which was something that prompted 9.3->9.4 for Jetty) since it would involve dramatic API changes.
I think this once again goes back to the poor definitions that I see floating around the Eclipse processes when I try and wedge non-osgi development practices like Jetty into it conceptually. I believe acknowledging this was the reason someone like me was was invited to this august body. :)
* Does it preserve the spirit of the current process?
In my mind the spirit of the IP policy is simple.
* Everything pushed out that may be consumed by a user should use and adhere to the current state of what you have in the projects IPlog.
This is the fundamental tenet we use when we make decisions on releasing Jetty. If we have updated a version of some dependency that is in any way exposed to a user when they use Jetty and we don't have it in our IPLog then we will not push out a release until we have it locked down. Everything we release to our users that involves a third party dependency should have a corresponding CQ.
So, in terms of perserving the spirit...if Jetty, or any of these continuous delievery projects push out a release under the proposed approach and the validation passes muster then spirit is preserved and what I believe are all the basic requirements of Eclipse are adhered to. If they broke something and widget X library wasn't passed through IP and it successfully passes after the fact then everything is still fine, spirit preserved and no harm done. If someone added a GPL library to their project and released it then there are problems and it is damage control time for the leadership of the project.
I'll note that the current Eclipse processes will not prevent this from happening either, it is totally possible to screw up and update the project and release something GPL that the formal Eclipse Release Review will not catch. In fact, it could be years before someone notices that something like that crept in without a validation process. As I mentioned, Wayne had a script that would troll through the downloads directory of a project and validate that things like the Jetty distribution passed muster but I do not believe that was a common event, and since we no longer put binaries on
download.eclipse.org it wouldn't catch anything anyway. The Eclipse Review Process is designed to ensure that Eclipse management is comfortable that a projects developers are aware of the IP policy otherwise it would involve actual validation of real release binaries before they were widely distributed.
cheers,
Jesse
