Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Architecture Council/Meetings/November 12 2015
| Meeting Title: | Architecture Council Monthly Meeting |
| Date & Time: | Thursday Nov 12, 2015 at 1100 Ottawa  HTML |  iCal
|
| Dial-in: | Let's use the Foundation's Asterisk setup for this call:
Participant conference extension: 701 then enter pin: 51968
|
Contents
Attendees
All AC Members are invited.
- PMC Reps please confirm attendance or list your delegate below. Every PMC is required to name a primary and backup delegate, and to ensure that one delegate attends the meeting.
| BIRT: | |
|
| DTP: | |
|
| Eclipse: | |
Dani Megert |
| Modeling: | |
Eike Stepper |
| Mylyn: | |
|
| RT: | |
Ian Bull |
| SOA: | |
|
| Technology: | |
Wayne Beaton |
| Tools: | Doug Schaefer | |
| WTP: | David Williams | |
All Attendees
- In attendance: Wayne Beaton, Marcel Bruch, Ian Bull, Konstantin Kommisarchik, Alex Kurtakov, Martin Lippert, Dani Megert, Martin O, Denis Roy, Doug Schaefer, Michael Scharf, Eike Stepper, David Williams, Krum Tsvetkov
- Regrets: Neil Hauge, Pascal Rapicault, Lars Vogel
Agenda / Notes
- Feel free to edit, but not during the call!
Review of Last Meeting
- Architecture Council/Meetings/October 8 2015
- Still open items moved to #Action_Items
New Topics
- Feel free to fill in, but not during the meeting :)
Denis: User Storage Service
- Based on Oomph "Preference Sharing", support putting Preferences on Eclipse Servers
- REST-Enabled, targeting Mars.2; Oomph initially but goal to give out more widely eventually
- Using the Eclipse Secure Storage model
- Will inform AC + a wider community as soon as V1 is committed and a staging server is available (should be very soon)
- Marcel interested in sharing simple things like username, E-Mail
- Wayne got good feedback on related talk at Java1
Wayne: EDP 2015 Update
- Tracked via a couple Bugzilla eg bug 463857 as root bug
- Opening up more to infrastructure like Github
- Changes have been approved by the Board of Directors
- bug 481703 Do we require the projects to use Eclipse.org build infrastructure ?
- Today, we require the Downloads to be hosted on Eclipse.org ; we do not require the builds to run on Eclipse.org hardware
- Marcel: Travis integrates nicely with Github, so forcing EMO would just be another pain point without too much value
- Kosta: It's a problem if access to the Build Hardware is not possible for all committers, and if EMO can't intervene (in case the project becomes inactive)
- David: Forcing EMO hardware would be a barrier for new projects to join Eclipse
- Removed the "Two Mentor requirement" for new projects, replaced by an "incubating@eclipse.org" mailing list
- Auto-subscribe all AC members auto-subscribed along with all new project committers
- Opt-out process
- The idea is that most questions will be generic about process rather than specific; have the ML act as a 2nd mentor
- AI Wayne post on the AC mailing list before taking action
Wayne: FEEP Process
- Initial https://projects.eclipse.org/development-efforts but we need more
- 12 bugs open already, prefixed with FEEP on the AC Bugzilla: http://eclip.se/5Z
- AI AC Members please discuss how to prioritize, start acting
- Marcel thinks that some requests have a too large scope for FEEP eg "Editor Autosave" may take weeks or months ?
- Is fixing bugs more important than anything else ?
- Dani: "Editor Autosave" discussion is going in a direction where he doesn't want to spend committer resources ...
- Was intended as a crash recovery mechanism
- Marcel: Voting on Bugzilla isn't transparent ... would prefer something like a Google Doc
- David: Would like to see some criteria eg size of the effort, # users affected, ...
- AI Marcel provide an initial spreadsheet and send to the mailinglist to get this started, ranking within the next 5 days
Denis: Infrastructure
- Added 4 HIPP servers recently - projects tend to prefer faster processors over more cores
- Github Issues vs. Bugzilla discussion
- Starting with a simple one-way "Save" such that we can continue in case something happens to GH
- Not going to do a full sync, especially not a 2-way sync - Doug agrees
Marcel: Mars.Rolling Stream
- David: Still on the Planning Council Agenda but not discussed in any detail yet
- Doug: The question was more about "how to get updates / emergency fixes" out
- Doug pushed 13 updates since the inception of CDT - thinks that supporting "Check for Updates" to fix bugs is really important (weigh out any risks) - Projects should enable their update sites
- Kosta: Update Sites pointing to new functionality makes it very unclear what one gets
- Today, it's almost impossible for anyone outside to produce a distribution with controlled update streams...
- Doug: In the end it boils down to the projects - Nobody stepped up to execute on Kosta's proposal
- Alex: Having update sites is valuable, should not instruct projects to stop doing that
- AI Kosta dig up the original thread and resend