Skip to main content
Jump to: navigation, search

Planning Council/May 04 2016

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, May 4, 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.)

For all phone lines: Participant conference extension: 710 then enter pin 35498
  • Ottawa (local call in Ottawa) 1-613-454-1403
  • North America (toll free) 1-866-569-4992
  • Germany (local call anywhere in Germany) +49-692-2224-6059
  • France (local call anywhere in France) +33-17-070-8535
  • UK (toll free) 0800-033-7806
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
  • SIP clients:
call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
Martin Lippert Cloud (PMC) Y
Chris Aniszczyk Technology (PMC)
Dani Megert Eclipse (PMC) Y
Sam Davis Mylyn (ALM) PMC Y
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC) Y
Ian Bull Rt (PMC) Y
Chuck Bridgham WTP (PMC)
Wayne Beaton Eclipse Foundation (appointed) Y
David Williams (appointed Chair) Y
Strategic Reps
Alexander Nyssen Itemis Y
Nick Boldt (and Max) Redhat (Strategic Developer)
Remi Schnekenburger CEA List (Strategic Developer)
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Stephan Merker SAP AG (Strategic Developer)
Markus Knauer EPP (appointed) Y
(has PMC rep; Dani Megert) IBM (Strategic Developer) X
Inactive
[no name] CA Inc. (Strategic Consumer) X
(was Gary Xue) Birt (PMC) X
(has/had PMC rep) Actuate (Strategic Developer) X
(was Rajeev Dayal) Google (Strategic Developer) X
Ed Merks Modeling (PMC) X
Adrian Mos (Marc Dutoo ) SOA (PMC) X

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

  • Wayne remind projects of Neon's critical dates and "new and Noteworthy". To quote
May 26/2016 - IP Log submission deadline
June 2/2016 - Review materials due

If you want your project featured in the aggregated new and noteworthy document [1], you need to set the New & Noteworthy URL field in the Review section of your project's Neon release record [2].

When it comes to marketing the release, it's really all about the end user IDE features. If you have any killer new features, please let me know ASAP.

Thanks,

Wayne

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=485299
[2] https://projects.eclipse.org/releases/neon

  • Any others?

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 Planning (and beyond)

  • There has been a lot of discussion about "giving up release name" and using "date" instead.
- Wasn't adding "build id" meant to do that?
- IMHO, classic case of stating a solution, instead of the problem.
- (Doug) IMHO, no. Let's not make sure this isn't a classic case of not listening to the community ;). We've talked in the past about giving up the names and using numbers, years or otherwise. A number of people in the community are letting their opinions be known, senior members of the community included. For more information, check Tracy Miranda's blog and the ide-dev list where much support was shown for her concerns including a well thought out discussion of the alternatives.
- To be explicit, I meant it is always better to state the problem to be solved, rather than a solution, and then everyone have their own interpretation of what problem it solves. In Tracy's Blog and the the one it mentions and the ide-dev mailing list thread, I have heard the following problems mentioned:
* Users do not know how old their install is
* Users do not know there is are more recent release
- They expect "update" would find it if there was a more recent one
* Users are confused by too many choices of packages ("which one is for Java")
* There are too many "brand names" (often in the form of acronyms -- and more in the form of "release code names" -- and now it has been proposed we add (not replace) even more information in the form of dates)
* So, my question remains, which problem(s) are we trying to solve by adding dates? Does it do that without replacing "code name" as originally suggested?
* Also, is this for "EPP Only", as this EPP Version proposal implies? If so, then the Planning Council does not need to be directly involved. It is EPP's decision (though I know there is overlap and there is no harm is us having a recommendation).
* Also, which location of code names are we talking about? Or where to add dates? We currently use "code names" in several places:
- Splash screen
- About box
- URLs (downloads, repositories, help)
- Many web pages
- Zip and tar filenames
- Marketing materials and press releases
- Plans and schedules
* [Do not read anything extra into me asking these questions -- I like several of the ideas I've heard -- I am merely trying to be explicit and set proper expectations of how much we can solve.]
* There is not much documented in past notes, but from quick search I found we discuss this topic about the same time of every year:
- Planning_Council/March_16_2014
- Planning_Council/March_04_2015
  • Had a long and winding discussion on this topic, but seemed to not be consensus on a solution. There was agreement there was a problem, but we were uncertain how large or widespread it was and how it would trade-off with a "complete change". For example, would "code name plus date" be sufficient, and provide an incremental change? Or do we need to eliminate the code name completely from external communications. The "original problem", some described, was new users not even knowing that the "release code names" were release/version code names, and somehow thought they were products or packages in and of themselves.
  • The conclusion, for now, was to ask Wayne to drive getting more "feedback from the community". Perhaps at Java One, perhaps a "quick poll" on download page. He will discuss with Ian the appropriate way.

ACTION ITEM: Wayne to discuss with Ian on how best to get more data from community of users.

old (ongoing) stuff

  • Should we change "maintenance" staging name now? for Mars.2? See bug 483475.
- [See also bug 483786 for unreleated additional URL.]
- Still "todo" item. (i.e. not done yet, apologies for delay)
  • 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?


  • "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?
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.
Seemed to be no objection to "trying it" and with Neon we will "try it" by having the "streamless-URL" proposed in bug 483786. For Neon, we will not use that URL automatically anywhere but users can add it if they would like. Will be interesting to see if many bug reports occur from people trying that "update to next main release" (that is, from Mars to Neon).

Oxygen Planning

  •  ?

New Business

Next Meeting

  • On 5/31 decided to postpone the June 1 meeting by one week to June 8th.
  • June 8, 2016 - Regular First Wednesday Meeting -- last meeting before release! (Unless we find a need for another.)

Reference

Neon Wiki page
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO

Copyright © Eclipse Foundation, Inc. All Rights Reserved.