Re: [jakarta.ee-spec.committee] Example spec release schedules

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

I think I'm still missing something basic...

What's supposed to be happening during the start/end time for a spec?
Staging occurs?  PR is submitted?  Balloting starts and ends?

Is this still assuming a 7 day ballot period?


Scott Stark wrote on 7/22/19 4:10 PM:
> The plan is a worst case staging plan that has the ultimate dependencies being the platform specs staged in time to just complete the two week ballot. The calendar in the program was not including weekends, so after changing that setting the plan has the platform specs being stage complete by Aug 26. If the ballot were started at the start of staging, that would easily give three weeks for ballot completion by Sep 10.
> 
> The stages are what is required simply for dependencies. Both Stage0 and Stage(-1) can start anytime. The other are based on dependencies, but I am figuring that we will be reviewing sets of staged PRs twice a week until complete, so that Stages also provide a rough schedule of what should be reviewed for ability to be used by the following stages dependencies.
> 
> Voting could be delayed until the final the start of the platform specs staging period starting on Aug 20, which would give 3 weeks until the Sep 10 target release date.
> 
> Voting could also be kicked off as soon as the spec committee is confident a staging PR is ready. I would think that we would want to take this approach to to finalize as many specs and TCKs as quickly as possible.
> 
> 
> 
> 
>> On Jul 22, 2019, at 3:39 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>>
>> I was just talking with Ed and we're confused about several things in
>> this proposed schedule.
>>
>> First, as Will pointed out, the review period can't be shorter than 14 days.
>>
>> I'm not clear on what level of review we expect to do *before* the ballot
>> starts.  There's about 20 specs with no dependencies.  We could start the
>> ballot for them as soon as they've submitted their PRs, then reset the
>> ballot date for them as we discover problems with them and need to update
>> the PRs.  Or, we do a lot of pre-review, get them to a state where they're
>> "perfect", and then start the ballot.
>>
>> Obviously with the first approach we would want to start the ballot ASAP
>> to allow time to correct problems.  With the second approach we could wait
>> until nearly the last possible minute before starting the ballot.
>>
>> And of course there are intermediate approaches.  How do people think we
>> should be doing this?
>>
>>
>> As for specs with dependencies...
>>
>> It's clear that the dependencies need to be staged before the things that
>> depend on them can be staged.  But they don't need to be final, and the specs
>> don't need to be approved, before the things that depend on them can start.
>> Obviously we can't approve a spec whose dependencies aren't approved, but
>> other than that there can be a lot of overlap in the ballots for dependents.
>>
>> Having some sort of staggered start to the staging is pretty much necessary,
>> but depending on how we do the balloting (as described above), there doesn't
>> necessarily *need* to be a staggered start to the ballots, although it might
>> still be a good idea.
>>
>> Another consideration is that there's *a lot* of stuff here to review.
>> Having a staggered start to the reviewing will help spread the load on the
>> specification committee out over time.  So there might be an advantage to
>> handling these specs in batches, but we couldn't tell whether that was the
>> intent of the batches in your proposed schedule.
>>
>>
>> Can you help us understand what you had in mind for reviewing and balloting?
>>
>>
>> Scott Stark wrote on 7/21/19 8:21 PM:
>>> I took the spec release dependencies that I had sent out to the spec leads list and put them in a Gantt chart that ran the project serially through their releases with the current two week voting period. This has the plane landing Oct 25. Clearly projects will need to release with overlaps and/or shorter review periods. I have also attached a version where every spec project is released in 7 days. This results in the final spec being released on Sep 6.
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>