[JSR348-56] Define the the time-out periods Created: 08/Aug/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to JSR348-4 Should Maintenance Leads be obliged t... Closed


1.3 JSR DEADLINES specifies that JSRs must reach Early Draft Review within 1 year, Public Review within 2 years, and Finale Release within 3 years, or else be subject to a JSR Renewal Ballot. Are these times appropriate, or should we shorten them?

Also, we've now decided to add a similar timeout for Maintenance Releases (not yet implemented.) The current suggestion for that is 90 days. Is that the right time?

Comment by keilw [ 17/Aug/11 ]

EDR somewhat sooner sounds reasonable. What value, e.g. 6 or 9 months, please suggest if you feel the same. Given the other two values all seem based on the same starting point, adjusting those to something like "Public Review within another X months/year" followed by "Final Release within another X months/year" sounds like a logical consequence.

That also better deals with situations where a PR of Final Draft has to be repeated. Whether or not the original time should be granted for that, I am not sure. We should avoid stretching it too far, but I guess steps like the Reconsideration Ballot should cover that and avoid too many failed attempts of a Public or Final Draft.

Comment by pcurran [ 26/Aug/11 ]

From Bill Shannon:

90 days is too short.

We often file MRs well in advance of the final release of the RI for the
platform. Knowing that the MR is approved and all we have to do is deliver
it helps reduce risk for the platform delivery. Being forced to submit all
MRs within 90 days of the final release, when we're trying to stabilize the
release, introduces unnecessary risk.

I greatly prefer the previous suggestion of asking the ML to specify when
the final materials for an MR will be delivered, and otherwise using the
general "JSR has failed to make progress" timeout mechanisms.

90 days between FAB and FR might be reasonable, and I understand this introduces
an asymmetry between a JSR and an MR, but it reflects our desire for MRs to be
low risk lightweight events.

Comment by pcurran [ 26/Aug/11 ]

Responding to Bill Shannon's comments...

I expected you to say that 90 days was too short - that's why I asked. I also understand the complications involved in synchronizing everything for a platform JSR.

However, I'm not sure what you mean when you say:

"I greatly prefer the previous suggestion of asking the ML to specify when the final materials for an MR will be delivered, and otherwise using the general "JSR has failed to make progress" timeout mechanisms."

If you mean that MRs intended to be included in a platform JSR should be subject to the same timeouts as the platform JSR itself then that makes sense (and is what I was planning to suggest.)

However, for MRs not intended to be included in a platform we need something other than "the timeout date is whatever the ML says it is." (We'd just get a bunch of MLs telling us that they plan to deliver before the end of the century.")

How about saying that the final release must be made within 90 days or - if the MR is to be included in a platform JSR - before the platform JSR itself is completed?"

Comment by Bill Shannon [ 26/Aug/11 ]

If the ML proposes a delivery date that's ridiculously far in the future, the
EC should vote against it.

I'd be fine if the MR->final bits and FAB->final bits timeout defaults to 30
days, as long as there's a way to request a different timeout and the EC gets
to approve it.

And I'm a bit worried if missing the timeout means you automatically go back
to the previous step, without a chance to update your timeout (e.g., because
your release slips). But on the other hand, I'm not sure I want to define
another EC ballot type to handle timeout updates!

Comment by pcurran [ 26/Aug/11 ]

The balloting process is already defined (JSR Renewal Reconsideration Ballot) though this will need to be generalized to cover Maintenance Releases as well as JSR development milestones. We wouldn't cancel a JSR or bump a MR back to the previous stage without review.

So: is this a reasonable summary of your proposal?

The ML chooses the deadline (if nothing specified, it defaults to 30 days.) This would presumably be done when the materials were submitted for the Maintenance Review. If the EC feels that the deadline is unreasonable they're free to vote 'no.' I'm sure that a deadline of "whenever the platform JSR that will include this update is shipped some time next year" would be an acceptable deadline. Alternatively, "we're planning to announce this standalone JSR update at our product show six months from now, but we want to make sure we have everything ready well in advance" would also be acceptable.

If the deadline is missed we go into the JSR Renewal Reconsideration Ballot process. In practice I'm sure the PMO would remind the ML, and would be flexible if they were told "we're a few days late, but it's coming Real Soon Now."

Comment by Bill Shannon [ 26/Aug/11 ]

Yes, that seems reasonable to me.

Comment by pcurran [ 19/Sep/11 ]

Despite lengthy discussion at the September f2f meeting we failed to reach agreement.

Some argued for much shorter time-out deadlines in order to "send a message" that we expect rapid progress. Others arguing for regular "reviews."

Patrick pointed out that we can't impose too much of a burden on the PMO, and reminded everyone that the purpose of this change is to permit us to deal with JSRs that are obviously stalled or inactive rather than to encourage people to work faster.

Needs further discussion at the next Working Group meeting.

Comment by pcurran [ 22/Sep/11 ]

As agreed during the September 21 Working Group meeting, we're going with 9 months plus 12 months plus 12 months. The relevant text now reads:

"If a JSR does not begin Early Draft Review within 9 months of completing its JSR Approval Ballot, or does not begin Public Review within 12 months of first submitting an Early Draft, or does not reach Final Release within 12 months of commencing Public Review, then the EC should initiate a JSR Renewal Ballot unless it is agreed that there are extraordinary circumstances that justify the delay.

I'm now closing this issue

Comment by Bill Shannon [ 22/Sep/11 ]

You said 9+9+9, but you wrote 9+12+12. Which did you intend?

Comment by pcurran [ 22/Sep/11 ]

Fix typos

Comment by pcurran [ 22/Sep/11 ]

Fixed the comment that Bill referred to. I meant 9+12+12

Generated at Thu Dec 08 11:30:22 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.