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

["MDeNicola@xxxxxxxxxxxxxx" <MDeNicola@xxxxxxxxxxxxxx>]

In the draft proposed revised JCP Process Doc that I sent to you, Section 3.6.5 introduces the concept of an simple Errata Maintenance Release that doesn’t require any Reviews unless an Executive Committee Member requests one and other EC Members agree.

 

Having to go through a Maintenance Review cycle when you have 6-month release cycles doesn’t make a lot of sense. However, the JCP/EC didn’t allow me to change Sections 3.6.1 through 3.6.3 because they wanted to be sure that there was a full Maintenance Review Process that could be used by OpenJDK if they wanted to use it. There is also the possibility that OpenJDK might at some time move to a 12-month release cycle, rather than the current 6-month cycle.

 

MikeD

 

From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx [mailto:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Monday, September 17, 2018 12:55 PM
To: jakarta.ee-spec.committee@xxxxxxxxxxx
Subject: Re: [jakarta.ee-spec.committee] Maintenance Review

 

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

---

This e-mail and any attached files are only for the use of its intended recipient(s). Its contents are confidential and may be privileged. Fujitsu does not guarantee that this e-mail has not been intercepted and amended or that it is virus free. If you have received this e-mail and are not the intended recipient, please contact the sender by e-mail and destroy all copies of this e-mail and any attachments. / Le présent courriel, ainsi que ses pièces jointes, ne peut être utilisé que par le ou les destinataires auxquels il a été transmis. Les renseignements qu'il contient sont confidentiels, voire même protégés. Fujitsu ne peut garantir que ce courriel n'a pas été intercepté ou modifié, ou qu'il ne contient aucun virus. Si vous avez reçu ce courriel sans en être le destinataire prévu, veuillez communiquer par courriel avec son expéditeur et en détruire toutes les copies et pièces jointes.