Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Maintenance Review
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?

_______________________________________________

jakarta.ee-spec.committee mailing list

jakarta.ee-spec.committee@eclipse.org

To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

 


_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


Back to the top