Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] First pass at EFSP 1.2

Thanks Kevin.

Is the wording regarding the 14/7 day ballot period confusing in the document, or just the change log?

In retrospect, I agree that a specification project must create at least one Milestone Build. I'll rework that back to the original form.

Wayne

On Mon, Jun 10, 2019 at 9:12 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Wayne,
Read through your PR, but I wasn't able to comment directly on your diff comparison...
>  - Clarification that all reviews are, by default fourteen (14) days; and must not be less than seven (7) days, see https://github.com/EclipseFdn/EFSP/issues/14.

I find this wording confusing.  Why default to 14 days if we are to allow for a 7 day ballot?  I thought the original requirement of a minimum 7 day ballot was sufficient.  What was the reasoning behind this change?

>  Leading up to a Release, a Specification Team should produce at least one Milestone Build.

Why did we change this from a "must" to "should"?  I don't think we want Release Reviews to happen if no milestone builds haven't happened.  Even MicroProfile requires at least one release candidate (milestone) build before we can declare a final release review...

(this same topic was restated around lines 305-308 and line 309)

Thanks, Kevin




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



From:        Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
To:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        06/09/2019 11:42 PM
Subject:        [EXTERNAL] [jakarta.ee-spec.committee] First pass at EFSP 1.2
Sent by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx




Greetings Specification Committee.

I've made my first pass at updating the EFSP to incorporate the changes that we've discussed (plus one other, I believe).

The changes are described here.

The short version is that the new version:
  • Makes the Progress Review requirement time based. Basically, a project needs to engage in a Review every 12 months. A Progress Review extends a Release Cycle; a Release Review ends it.
  • Specifies that a ballot requires 14 days by default and must not be less than 7 days.
  • Describes a formal exception process.
I'll update the corresponding issues tomorrow. While "putting pen to paper", additional constraints presented themselves...

Your feedback, even just initial observations are welcome.

I will take another pass tomorrow and send you an update.

Thanks,


Wayne

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc._______________________________________________
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://www.eclipse.org/mailman/listinfo/jakarta.ee-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://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


Back to the top