Difference between revisions of "Architecture Council/Meetings/March 9 2017"

Revision as of 13:00, 9 March 2017

Meeting Title:	Architecture Council Monthly Meeting
Date & Time:	Thursday March 9, 2017 at 1100 Ottawa HTML | iCal
Dial-in:	See Eclipse Asterisk : 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 Switzerland (local call anywhere in Switzerland) +41-44-580-2115 Spain, Sweden, others - see Asterisk/Numbers Participant conference extension: 701 then enter pin: 51968 SIP clients can call 701@asterisk.eclipse.org, then enter pin 51968.

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.

Next Meeting

• Architecture Council/Meetings/April 13 2017