Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Jakarta Activation 1.2.2, XML Binding 2.3.3 and XML Web Services 2.3.3 release review

Whether or not (and how) ballots should be batched is entirely at the discretion of the specification committee.

The specification committee runs ballots for their specifications. I am calling and running ballots in my capacity as the delegate of the specification chair, not as the EMO.

Wayne

On Thu, Feb 6, 2020 at 6:59 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
I suppose it's fine to do the Eclipse project reviews as one batch review, but I would expect the JESP spec reviews to be done separately for each spec.


Wayne Beaton wrote on 2/5/20 8:00 AM:
Kevin is correct. The specification committee ballot is concerned with a project level event (release/review). For projects that include more than one specification, a single release/review is the expectation. This is what we did during the first round of ballots.

I was hoping for some feedback from the specification committee that the descriptions of the releases are sufficient before calling the ballot. That is, is 'First release going through the JESP.  Bug fix release of 2.3.2. This service release includes an update to the Jakarta XML Web Services 2.3 Specification, Jakarta SOAP Attachments 1.4 Specification and Jakarta Web Services Metadata 2.1 Specification." enough for the specification committee members to vote on? What more does the specification committee want to see? For an answer to that, we (or, more specifically, the project team) really need to engage the specification committee (e.g., David started a discussion regarding the Jakarta Enterprise Beans project release)

According to the JESP, we need 14 days to run a ballot for a service release, so I need to call that ballot today (or tomorrow at the latest) if we want to release on February 19.

Wayne

On Wed, Feb 5, 2020 at 8:59 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Bill,
Since these other projects are contained in the same Eclipse Project, it doesn't make any sense to duplicate the effort of scanning and the iplog reviews from an Eclipse process viewpoint.  We ran into this same condition with MicroProfile.  Since all of our components are contained within the same MicroProfile project, all of the github repos are referenced when creating the iplogs and the scanning of the code.  So, we only submit the top-level MicroProfile project for review and the other component reviews are implied or included.  MicroProfile is kind of a special beast since everything is contained within a single Eclipse project.

Lukas has a similar condition but at a smaller scale.  Three of these components are contained in the single XML Web Services Project -- XML Web Services, Web Services Metadata, and SOAP Attachments.  Thus, there is only need for a single iplog and code scan and Eclipse review for all three.  I'm pretty sure this is what Lukas was referring to.

We still need to do the full Spec reviews which we are doing via the PRs.

Hope this helps.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        Bill Shannon <bill.shannon@xxxxxxxxxx>
To:        EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx>
Date:        02/04/2020 17:34
Subject:        [EXTERNAL] Re: [ee4j-pmc] Jakarta Activation 1.2.2, XML Binding 2.3.3 and XML Web Services 2.3.3 release review
Sent by:        ee4j-pmc-bounces@xxxxxxxxxxx




Lukas Jungmann wrote on 2/4/20 6:49 AM:
> On 2/4/20 3:07 PM, Kevin Sutter wrote:
>> +1 from me.  Thanks, Lukas!
>>
>> Question:  What about SOAP attachments and Web Services Metadata?  Will those
>> be coming on a later request?
>
> they are supposed to be covered by 'Jakarta XML Web Services 2.3.3' which is
> top-level project for both + Jakarta XML Web Services itself (to not spam
> everyone that much with copy-pasted stuff). For the next major version, release
> records were already splited up to allow separate evolution of each part in the
> future.

They're separate specs, they need to be approved separately.
They should be considered part of this bundle of requests.

Lukas, please provide the release review details.

_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc




_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


Back to the top