Re: [jakarta.ee-spec.committee] Maintenance Review

[Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>]

The Eclipse Development Process already has a much lighter-weight approach to bug fix releases (aka errata). They don't require a full Release Review, for example.
Wayne is currently trying to focus on getting a complete draft of the process complete. Let's give him a couple of days to respond, but I am confident that we can address this issue in a manner which is at least no more heavyweight than the JCP.

On 2018-09-17 9:28 AM, Richard Monson-Haefel wrote:

I think an MR process is still needed and I agree with Bill that it should be lightweight.  I support the idea that an MR requires a single vote by the Spec Committee.  

Sometimes these changes can be time critical. Especially, if the error being addressed is impeding adoption or causing issues in the wild.  We have to let spec projects update quickly but still provide some oversight.

On Fri, Sep 14, 2018 at 3:16 AM, Werner Keil <werner.keil@xxxxxxx> wrote:

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
Sent: Friday, September 14, 2018 01:20
To: Jakarta specification committee
Subject: [jakarta.ee-spec.committee] Maintenance Review

 

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?

_______________________________________________

---

This email has been checked for viruses by Avast antivirus software. www.avast.com