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/March 9 2017
Meeting Title: | Architecture Council Monthly Meeting |
Date & Time: | Thursday March 9, 2017 at 1100 Ottawa HTML | iCal |
Dial-in: | See Eclipse Asterisk :
Participant conference extension: 701 then enter pin: 51968
|
Contents
Attendees
- In attendance: Carl Anderson, Mickael Barbero, Wayne Beaton, Marcel Bruch, Christian Campo, Jonas Helming, Jim Hughes, Mickael Istria, Maximilian Kögel, Marc-Andre Laperle, Martin Lippert, Dani Megert, Alexander Nyßen, Martin O, Denis Roy, Doug Schaefer, Gunnar Wagenknecht, Tom Watson
- Regrets: Jay Jay Billings, Mike Wilson, Pascal Rapicault, Krum Tsvetkov,
#PMC_Rep_Attendees see also below.
Agenda / Notes
- Feel free to edit, but not during the call!
- Last meeting: Architecture Council/Meetings/February 9 2017 -- open actions see #Action_Items
General Topics
- New Members - Wayne to nominate 1 or 2 more candidates from locationtech; Jonas to nominate one
- Since Locationtech people are not so known to the current AC, might not get so many +1s
- Consider changing voting procedures to require fewer than 50% of the active +1
- RESOLUTION proceed with the nominations now, reconsider next month
- Marcel - Marketplace: All Solution Providers got an invitation to use the AERI for own plugins
Denis: Bugzilla
- Account moderation had been enabled
- Thanks to collaboration with GNOME community, one of their spam prevention plugins could be installed
- Deployed on Polarsys and Eclipse bugzilla - working great so far
- Bugzilla version is old, but upgrading needs service upgrades too (planned for the summer)
Denis: Servers
- 7 new servers deployed, 4 more to deploy in the coming weeks (in order to regain stability)
Wayne: Mentoring
- Struggling to find mentors
- Marcel: Don't see questions from mentored projects, so unsure about the benefit of mentoring
- Wayne: Some projects violate Eclipse principles; Foundation is improving communication to alleviate this, but is it enough?
- Jonas: When Eclipse opened up to IoT, Locationtech ... domains are unknown to many old-timers;
- bring in more people to the AC? Or form a new (less formal) group of possible mentors, other than AC
- Projects which have been in the ecosystem since 1 year or so might be more willing to mentor other newcomers
- Jim: Been mentoring Locationtech, but the Locationtech Community is really disjoint with AC
- AI Wayne create 2 Bugzilla's for discussion ("advice for mentors", and "changing the definition of the mentor pool"
- There might be an option for refocusing the AC, to be discussed separately
Wayne: Dockerhub
- Wayne has been given the keys to upload Polarsys and Locationtech; keys are available for anyone who wants to experiment with this
- Che started doing some work with this
- Not an official EF distribution channel yet, thus not imposing IP policy rules as of today ("let it happen for a while")
- A bug is open for discussing the process
- Jim: For Geomesa this has been very useful; Quaid is also looking at it; more lightweight process for distributing complete systems is very appreciated
- Jim: In terms of pattern and practice, make it clear how to build a docker image (then it becomes clear what went into it)
Wayne: Security
- Couple bugs is open regarding security policy
- Consider alternative channels for projects to use, but don't want too many ... channels need to be private
- Github currently doesn't have a mechanism for private communication
- Right now there are 2 entrypoints -- Bugzilla, and Mailinglist; 2 bugs open for discussion
- Jim: Dealing with security issues in downstream libs -- need to raise a CQ for upversioning dependent libs
- Process is very heavy, could this be expedited in the IP process?
- Wayne: PMCs need to react timely; when the IP team is told about urgency, they should be able to expedite
- Wayne: There was a board resolution that "pure service release uprevs of a lib don't need a new IP Review, no CQ process"
- If any functionality / APIs are added, we're back to the normal process; but for pure bugfixes, no CQ is needed
- This was discussed in the Board more than a year ago (AI Wayne add exact reference)
- If CQ list gets out-of-sync with the acutal libs, Wayne has tooling to consolidate; for final contents in a Simrel, creating a CQ might still make sense ... but not for milestones in-between
- Dani and Martin think that minimal tracking in a CQ would help just to document that a security issue is resolved
- Wayne: Hybrid approach - could use a lib right away and have CQ entered for tracking in parallel ... don't do unnecessary work. Projects can have their own policy.
- Mikael: Documenting the ability to not have a CQ might actually introduce more complexity than the uniform and consistent approach we have now...
- Dani: How to validate it's really just a bugfix and doesn't violate any IP? - Wayne: Would be the committer's duty to review
- RESOLUTION: If unsure, talk to the IP team and create a CQ for discussion. Leave it to a committer to decide if it's just a bugfix and thus a CQ is needed or not.
Devoxx US / EclipseCon NA
- AI Maximilian Quick poll on the mailing list for a F2F meeting
PMC Rep 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: | |
|
Mylyn: | |
|
RT: | Christian Campo | Tom Watson |
SOA: | |
|
Technology: | Gunnar Wagenknecht | Wayne Beaton |
Tools: | Doug Schaefer | |
WTP: | Carl Anderson | |
LocationTech: | Jim Hughes | |
IoT: | |