Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.

Mars Planning

Neon Planning

At our previous meeting it was decided to have 3 update releases (instead of current 2), and have them approximately equally spaced:

June (3) September (3) December (3) March [(3) June]

* I propose we plan the availability of Update Releases to be the same as the end of specific Neon+1 milestones.

- That would be M2, M4, and M6. (See Neon's schedule, for a rough idea of when Neon+1 milestones would be.

- There was a general agreement this seemed reasonable, but, some wanted more detail, such as how "test time" would line up, for the milestone vs. update releases. So that will be the next step, for me to map our some detail, and show both milestones and update releases on same schedule or calendar.

- The "two milestone pattern" (one-week-window period)

Stream/Week

0

1

2

3

4

5

6

release day

0

1

2

3

4

5

6

release day

master

dev

dev

dev

dev

dev

stabilize/+0

+1 to release

Odd Milestone

dev

dev

dev

dev

dev

stabilize/+0

+1 to release

Even Milestone

maint.

dev

dev

dev

dev

dev

dev

dev

dev

dev

RC1

dev

RC2

RC3

RC4

Quiet Week

Maint.X

- The "two milestone pattern" (two-week-window period)

Stream/Week

0

1

2

3

4

5

6

release day

0

1

2

3

4

5

6

release day

master

dev

dev

dev

dev

stabilize/+0

dev

+1 to release

Odd Milestone

dev

dev

dev

dev

stabilize/+0

dev

+1 to release

Even Milestone

maint.

dev

dev

dev

dev

dev

dev

dev

dev

dev

RC1

dev

RC2

RC3

RC4

Quiet Week

Maint.X

Questions on patterns:

Do we still need the RC1 "warmup" to be two weeks "early"? I think nearly all projects are so good at this, we no longer need a "warmup" and could jump right into "real" RCs.

Do we still need the "two-week-window pattern? Or, is one week always enough? Again, I think it speaks to the skill of the projects that we may no longer need it.

- This has one obvious advantage: for projects that are essentially working on one stream only (such as fixes-only, especially for first Update Release), they can submit same content to the Update Release, and the Milestones stream.

- Nick suggested: Would this be a good time to look at changing the /staging/ and /maintenance/ URLs so they're *release-specific*?

- Also, looking at the schedule, the December "match up" seems a no brainer ... not much other time to do it?

- M6 matching the last Update Release is nice since gives "clear focus" for M7 and the end-game of Neon+1.

- And Neon.1 matching M2 completes the rhythm.

- From those "end dates" we would count backward, to establish the same RC pattern we have now.

- I've not looked closely, but believe the first "warmup" RC, would be same or near the previous Neon+1 milestone. (one quiet week, plus 3 one week RCs, plus 1 two week RC equals 6 weeks) [Is that good or bad? Do we still need that early warm up RC? (I'm inclined to say yes, if for nothing else, "new projects" joining the train, and for those adding minor feature updates -- we still want a relatively early warm-up for them, similar to an update release milestone).

Can we say now we all agree with these dates? (I suggest "official vote" for next meeting, but if disagreement or concerns speak up now!)

Has everyone had a chance to talk to their PMCs, Projects, or Strategic Members they represent? (Please do, we need, and want, complete buy-in from all stack holders -- that is, not so much what we dictate, as it is what they want ... or, at least tolerate).

Off-cycle "hot fix" releases/patches. This is being tracked in bug 483322.

- We did not discuss this topic much, at 10/7 meeting.

One proposal: have all features in EPP packages be "root features" and establish a procedure of adding new code to the Sim. Release repository "at any time" -- for "hot fixes" only ... after review/approval by Planning Council?

(Would likely have to be a "product preference" since some adopters may depend on that feature, but EPP could "set" the preference).

Easy for me to say "change p2" :) but ... who would do the work?

This "reference repositories issue" was a discussed as a concern at Architecture Council

Apparently there have been cases of users getting "mixed" installs because reference repositories are sometimes very broad. [I hope I've captured that issue correctly, I was not there, so please correct if I read it wrong.]

Does Oomph solve this problem at all? Does it have a possible solution?

Rolling "release" issue

- We did not discuss this topic much, at 10/7 meeting.

Upon re-reading, that was another topic discussed at Arch. Council.

Probably several ways to solve ... if it is a real issue? ... and, if I understood what the "end goal" was better?

Neon new requirements

If a bundle is already signed by "Eclipse" it must not be re-signed.

Projects must provide b3aggrcon file change for every new contribution. Either change exact feature versions if pointing to a composite or change URL if pointing to a simple repository. (i.e. No more "set it and forget it" practice of pointing to a composite, and hoping the correct "latest version" gets picked).

others?

New Business

Any volunteers to drive the naming of "Neon + 1"? We normally start this process in December or January.

TODO: It was mentioned at a previous meeting it would be nice if not important to "rekindle" the face-face meetings at EclipseCon NA ... or, some other form of more active Planning Council participation, such "meeting your Planning Council Rep Hour"? (or BOF?)