| Re: [jakarta.ee-spec.committee] Maintenance Review |
Shouldn’t the Jakarta EE process work a Little more like the new Iterative JSRs at least for specs that are actively developed and not „stable“ or „dormant“? Does the MR still work for iterative JSRs? I have not looked at every line of what MikeD shared but if a JSR has two or more releases each year, the whole idea of a MR seems a little unnecessary for these. Werner Sent from Mail for Windows 10 From: Bill Shannon I realized after our meeting today that we don't have something similar to the JCP Maintenance Review process, or a simple process to handle errata. Assuming a simple API update that would've been done with a JCP Maintenance Review, the EFSP would require a Spec Committee vote to start a new version of the spec, a Spec Committee vote to approve an interim draft of the spec, and a Spec Committee vote to approve the final version of the spec. That's *a lot* more heavy weight than the JCP MR process. Do we really think we should have exactly one process that is used for all changes large and small? And what would we do for an errata update to a spec? That wouldn't create a new version of the spec so would there be still be three Spec Committee votes to fix a bunch of typos in the spec? Or would there be no Spec Committee votes for errata, handling them entirely within the Spec Project and releasing an update to the spec document? That's significantly lighter weight than the JCP, which would use the MR process, but do you want to allow the release of new revisions of the spec document without any oversight by the Spec Committee? _______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee |