October_07_2015.md
October 9, 2023 ยท View on GitHub
Logistics
Meeting Title: |
Planning Council Conference Call |
Date & Time: |
Wednesday, September 2, 2015, at 1200 Noon Eastern |
Dial in: |
(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.) Phone Numbers: (Check Asterisk/Numbers for more or current phone numbers.)
|
Members and Attendees
width="100%" valign="top" |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
width="100%" valign="top" |
|
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.
Note: feel free to correct any errors/omissions in above attendance record. Y = Yes, attended N = No, did not R = regrets sent ahead of time D = delegated X = not expected
Announcements
- Welcome Sam Davis as new (official) PC rep from Mylyn (ALM) PMC; and thanks to Steffen Pingel for his years of service.
Previous meeting minutes
- Review previous meeting minutes if you'd like. That is, review them before meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.
Mars Planning
- Mini Mars.1 retrospective:
-
- Some (committers) expressed ?surprise? that new projects could "join train". (I think "surprise" is the right word?)
\- Doug has mentioned "we need to socialize the changing rules better" (Anyone know how, and able, to do that?)
-
\-*No one in attendance knew "how to socialize better" to
committers.*
-
\-*During meeting, also discussed need to communicate better
with "community", consumers, adopters, occasionally even "the
press".*
-
\-*One suggestion was to ask projects "what is new and worth
mention in marketing materials", as we do for the June
release. It wouldn't expected to be as long a list, but,
best to have something to say about it. Even if "bug fixes
only", that's fine, but best to say. Might be nice to as for
"number of bugs fixed" or even links to queries that listed
the bugs fixed?*
\-*It was also learned that we should communicate "slipped
dates" better. At minimum, update the Planning Council calendar
and various wiki's to mention the new date.*
-
- The respin
\- Seemed a borderline case, to me. But, in the end, glad we did. Not just for workspace dialog issue, but also improved repo and packages to include only one (latest) version of com.jcraft.jsch. That in turn was "lucky", since Eclipse.org infrastructure upgraded and quietly included only "latest" Ciphers. Unclear if really only needs to be one, like a singleton, but there have been reports of "uses constraints violations", when both present. \- Then there was (some) surprise about the "one week slip" in releasing. - \-- Of all "lessons learned", I like the idea of "if we rebuild during quiet week, then automatic one week slip in schedule". \-- Not only makes gives time for others to re-test, or adopters to rebuild, but makes it easier for me and Markus. \-- I plan to codify this practice in the Sim. Release Plan. Any objections? See [addition to Mars Plan](Mars/Simultaneous_Release_Plan#Mars.1 "wikilink").
-
\-*There were no objections to adding this explicitly to plan
documents.*
-
\- As a side observation, the workspace dialog bug was
introduced by a code change on June 6, which (partially)
validates our caution by allowing Buildship to join in June. The
bug had been reported earlier (than last week of Mars.1) but a
fix was not known before then. Thanks again to Tom Watson for
providing the correct fix ... otherwise, would have still be a
problem (albeit rarer) if we had re-spun with originally
proposed fix.
Neon Planning
- See initial working draft of plan at Neon/Simultaneous_Release_Plan.
- - Neon's 2016 Milestone Dates (M5, M6, M7, and RCs)
-
See [Neon's
Schedule](Neon/Simultaneous_Release_Plan#Schedule "wikilink")
Similar to last year (EclipseCon is similar dates, as last year
-- but on East Coast again\! Yeah\! :)
Do we all agree with those dates? (That is, can we declare them
now official?)
-
\- *There was agreement with these milestone dates. Nothing
controversial, or, changing from previous years.*
- - Neon's Update Release Dates
-
At our last 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 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.*
-
\- 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\*? eg., instead of:*
\* ''<http://download.eclipse.org/releases/neon>, ''
\* *<http://download.eclipse.org/releases/staging>,*
\* *<http://download.eclipse.org/releases/maintenance>*
*... we could do*
\* ''<http://download.eclipse.org/releases/neon>, ''
\* ''<http://download.eclipse.org/releases/neon-staging>, ''
\* *<http://download.eclipse.org/releases/neon-maintenance>*
*... so as to differentiate staging of update releases
(maintenance) from staging of .0 releases (staging) and avoid
conflicts between mars/neon or neon/neon+1 URLs.*
-
\-*Post-meeting observation from David: If we had release name
as apart of the URL, we would not need "maintenance" just
"neon-staging" and "mars-staging"*
-
\- Also, looking at 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 backwards, 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 train, and for those adding
minor feature updates -- we still want a relatively early
warm-up for them, similar to a 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.
- - 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? AND, change p2? to "not allow" addition of reference repositories during feature installs.
- (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?
- - [ACTION ITEM from previous meeting] Wayne took as a "to do" item, to check with IP staff if a CQ deadline should be set for update releases.
-
\- Cons (probably not needed): there are few new ones, every one
knows the limits
\- Pros (would be helpful): helps set expectations of committers
and new contributors on how much can be done, by when.
-
(Though, still varies a lot, if "all new" large
contribution, vs. piggy back CQ)
- -- Wayne reported that at this time, no deadline needed. Might change in future, as experience and new patterns emerge. But, nothing obvious at this point, other than a general awareness that "the earlier the better" and that all requests can not necessarily be satisfied, depending on size and timing.
New Business
- ''It was mentioned it would be nice, if not important, to "re-kindle" the face-face meetings at EclipseCon NA ... or, some other form of more active Planning Council participation.
Next Meeting
- November 11, 2015 - Regular First Wednesday Meeting -- on 'Second Wednesday'!
- - at 10/7 meeting, decided to have on Second Wednesday, so as to not overlap with EclipseCon Europe (Nov. 3 to Nov. 5).
Reference
- 2013 EclipseCon face-to-face follow-through action items. For original meeting notes, see March_24_2013 and for discussion leading to action items, see April_10_2013. For last status update, see May_8_2013.