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
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.
|Tools:||Doug Schaefer|| |
|WTP:||David Williams|| |
- 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
- 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 "firstname.lastname@example.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
- 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