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
Wayne,
I find the 14/7 day ballot periods in both the change log and the document.  I'll admit the change log is what first caused me to say "huh?".  But, then the doc itself just clarified the "huh?"  :-)  I can understand that we need to clarify the original "one week" to mean "7 days", but why not just say that's the default and minimum?  And, it can be extended to 30 days for the reasons specified.  I'm just concerned that some people might read the 14 day as default and assume it's the minimum.  We would then have to clarify it for those that read it too quickly.

Thanks!


---------------------------------------------------
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/10/2019 11:46 AM
Subject:        [EXTERNAL] Re: [jakarta.ee-spec.committee] First pass at EFSP 1.2
Sent by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx



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._______________________________________________
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


Back to the top