Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Planning Council/September 07 2016
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, June 8, 2016, 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
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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
- Special Guest: Fred Gurr
Previous meeting minutes
- Review previous meeting minutes if you'd like. That is, review them before the meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.
Neon maintenance
- Nearing Neon.1. Any issues?
- WindowBuild is back in RC3 at the declared version level (1.9.0).
- BPMN2 Modeler is back in since RC1 at 1.3.1 level.
- Will soon need a Neon.1 info center (bug 500938)
- Create New and Noteworthy for Neon.1 (bug 500939)
- - Wayne did volunteer to do N&N for Neon.1
Oxygen Planning
- There has been a lot of discussion about "giving up release name" and using "date" instead. See bug 493490.
- - Further discussion in the meeting lead to the idea that one thing that is missing is what DO we call the "think" we are releasing. "Eclipse Neon" seems too vague and definitely sounds like a different thing than "Eclipse Mars" (even if you add "release". Some quick suggestions were "Eclipse IDE - Neon Version" or similar (with dates, probably).
- - ACTION ITEM: Doug said he would try to re-ignite the discussion via blog or similar.
- - Main point is that we owe the community some response on bug 493490 about what our plan will be.
During today's meeting, it was decided that we can not "solve" for Oxygen, but we can probably make incremental improvement. After that incremental improvement, we may have a better idea of the core problem to fix. As things are now, there is little chance of getting agreement on what the problem is or how to fix it. It is sort of like now the problem is "things are confusing" -- a little too broad to fix all at once. I will comment in bug 493490 that we don't want to abandon the name, but that in general, any place the "code name" is used there needs to be more information, such as version or date or build id (depending on context). Also, I think that "check for update" should give some indication that a "whole new stream" is available -- as the Installer currently does.
- Should we change "initial disable" practice? (See bug 499462.)
- - Is this an actual problem, or working as designed?
- - If working as designed, perhaps we should at least improve expectations, somehow.
- - Or is there a way to improve "automation"? Such as, once "declare intent" they automatically get "re-enabled" (even if project intends to change contribution at some point).
- - Or, at least, can we improve documentation?
It did not take long to reach a consensus that it "punishes" those that are trying to do things well, and does not give us very good data on 'who is not participating'. Hence we will return to "leave enabled" (except when a project explicitly withdraws). AND we will come up with some other ways to check on who is not participating (in the sense of "paying attention"). Some brainstormed ideas of doing that were: check if Git revision of aggrcon file has changed from milestone to milestone or check if feature versions have changed from one stream to another. Those things not changing would be "red flags" and cause some questions to be sent to the project. M4 will remain (or return) as the deadline to formally declare (for everyone, old and new projects) even though there is an implicit "opt-in" for M1. Part of the reason to wait until M4 is that most projects are not even thinking about "the next major release" ... they are working on update releases and the input to the update release and the "next" one is the same -- especially now that we have gone to quarterly updates.
- Two projects "leaving":
- ECF (See Sam's post to PC list).
- Riena (See Christian's post to cross-project list and bug 500733 mentioned in that post).
We discussed if a) this was a sign that things were too hard and b) if projects using a non-participating project was going to cause problems. None of us have heard concrete cases of "item a" and it seems to be more a matter of "other things becoming more important" to the committers on those projects. As for "item b", it may or may not be a problem. Since we can not "force" projects to participate and since it would be detrimental to say that projects could not "include" non-participating project releases our only option seems to wait until there is a known problem, and then solve as they come up. The solution could be that some part of the "required prereq" moves to a project that depends on it. Or, perhaps someone else becomes a commtter on that prereq project to make fixes that they need it to have.
old (ongoing) stuff
- Release Policy vs. Release mechanics. This is being tracked in bug 483322.
- In M6 we changed to have (nearly) all features to be "root features.
- Now what? That is, can we "stop" adding "reference repositories" via feature p2.inf files?
- "Rolling release" issue.
- I have sometimes heard it suggested we allow more of a "continuous release". Is this something we should discuss? Should we have some long term planning for it? Such as, what would it take to accomplish that?
- This could be planned with or without the "beta stream" mechanisms sometimes discussed.
- Did not discuss much during this meeting, other than to note similarity to above issue.
- Should the ability to update from yearly release to yearly release be a 'requirement'?
- Impossible now, for Neon. Right? (for EPP Packages) Do we still need "streamless-URL" now? I am assuming "no".
- ACTION ITEM from 6/8 meeting. Doug volunteered to "take up" this item to better specify "what does it mean" and "what will it take" to update across major releases. [Doug, it is up to you, but I suggest you form a small team of like 3 people, such as Ian and Dani or, others who know some of the technical issues, to help if they are able and willing.] The goal being just a more specific statement of what it means, and what projects have to do differently for Oxygen. That is, we don't need to reach Nirvana in one release cycle.
- What would this take? (Such as features are never "just removed" but are replaced or transitioned?)
- Preferences, views, etc. have to "migrate" (if their ID changes).
- What testing would projects have to do?
- May become "defacto requirement" once bug 483786 is implemented.
- For Neon we will not have a "streamless" URL, since "won't work" for upgrading to Neon for the EPP packages.
New Business
- Dani: Does any feature, independent how small (e.g. new option), force a release review for the Update release? Does it require full review doc, or is there a way to report just the features + e.g. new IP log?
- - Good question, for Wayne? I think technically the answer is "yes" unless something has been simplified?
- In a similar vein, who is responsible for the "New and Noteworthy"? I think Wayne did a "combined one" for the initial release. From looking at the version comparison reports it appears about 10 projects have "new minor increments" ... plus the two that have "rejoined" the train. I have opened bug 500939 to cover the specifics. But, am not sure who is the responsible "author" of the document.
- The remaining "new business" items are from previous meetings. I am not sure they resolved so left them for now.
- Wayne could not make the meeting, but posted a message to our mailing list about concern over some specific projects -- some of which may have to be "removed" from the train. But, in addition, expressed concern over "the process".
- - I agree and commented on a similar issue on cross-project list about two projects who "declared intent", but thought they could join the build at the last minute.
- - I wondered out loud if it was time for more of a Sim. Release process where projects had to "prove they were ready to be in the Sim. Release" instead of us just saying what they needed to do, and then assume they were doing it. We did not discuss at this meeting, but, for example, I mean like a checklist (web app) that has to be updated every milestone? Just an idea.
- A question was raised if people have to "announce" they will be in "Neon.1" if they were in Neon. The answer was "no". [Did not mention it at meeting, but they should announce if they are NOT going to be in Neon.1.]
- - This led to a brief discussion if projects should "rebuild" if their prereqs change. For example, if a security bug is found in an Orbit bundle. A few thought "yes", but seemed the consensus was "there was no way we could force them to" (i.e. can not leave them out, or else their "previous release" would still be there with the bad bundle) and it was probably a fringe enough case we did not need to have a rule about it.
- A question was raised how we can avoid issues such as with Neon where Window Builder was excluded for Neon. They were ready at the very very last minute but had not done any builds or testing for all of the Neon development cycle. Somehow, we should "detect" when projects are not active so we can approach them early to find out if the project is viable if they are testing, etc.
Next Meeting
- October 5, 2016 - Regular First Wednesday Meeting
Reference
- Draft Eclipse Project Branding Requirements (Wayne)