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.
Difference between revisions of "Architecture Council/Meetings/June 12 2014"
(→Next Meeting) |
|||
Line 172: | Line 172: | ||
== Next Meeting == | == Next Meeting == | ||
− | * [[Architecture Council/Meetings/July | + | * [[Architecture Council/Meetings/July 10 2014]] |
[[Category:Architecture_Council_Meeting_Minutes]] | [[Category:Architecture_Council_Meeting_Minutes]] |
Revision as of 12:02, 12 June 2014
Meeting Title: | Architecture Council Monthly Meeting |
Date & Time: | Thursday May 8, 2014 at 1500 UTC / 0800 SFO / 1100 Ottawa / 1500 London / 1600 Berlin attention DST change 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: | Brian Payton | |
Eclipse: | |
|
Modeling: | |
Eike Stepper |
Mylyn: | Steffen Pingel | |
RT: | |
Tom Watson |
SOA: | |
|
Technology: | |
Wayne Beaton |
Tools: | Doug Schaefer | |
WTP: | Chuck Bridgham | |
All Attendees
- In attendance:
- Wayne Beaton, Marcel Bruch, Ian Bull, Jonas Helming, Maximilian Kögel, Martin O, Steffen Pingel, Denis Roy, Doug Schaefer, Eike Stepper, Krum Tsvetkov, Tom Watson
- Regrets: Christian Campo, Neil Hauge, Markus Knauer, Adrian Mos, Gunnar Wagenknecht
Agenda / Notes
- Feel free to edit, but not during the call!
Review of Last Meeting
- Architecture Council/Meetings/May 8 2014
- Still open items moved to #Action_Items
New Topics
- LTS naming convention (Wayne)
- LTS working group: How to identify artifacts that are produced by the LTS forges ? (for support scenarios)
- Eg Open Source "Eclipse Project X" receives a bug report, but maintainer of "project x" has never heard about that version
- Idea: Use JAR signing - have LTS forge use its own certificate (available for LTS members to use when bundles come from a "collaboration forge")
- Plus, special kind of "qualifier" to indicate LTS (dashes/underscores could confuse some tooling; monotonic increase of version)
- Plus, build ID (from the About Dialog)
- Ideally, want something in the build infrastructure that doesn't count on an LTS committer making the right change
- Ian: Could also just put verification into the build ("fail if qualifier doesn't end with -lts")
- Ian: Need restrictions on what version digits may be increased by LTS (Martin: 3rd digit only)
- Martin: "how obvious" does it need to be that the bundle comes from LTS (eg what about "Provider: Eclipse LTS") ?
- Wayne: Concern was that this requires changing the source
- EPL: Derivative work must be "made available" (typically/hopefully as patches back upstream)
- Likely looking at a corner case here, since "lts customes" will come to their lts provider first. Bundle version number is most important.
- LTS working group: How to identify artifacts that are produced by the LTS forges ? (for support scenarios)
Marcel: Update on Logging
- GSOC is making good progress. Apache Commons, Log4J, and SLF4J are loggged to a EclipseLog appender. Configuration is done via logback.xml which is loaded from an expanded plugin folder. More details probably on the next meeting.
New AC Member Candidates
- One from Ian
- One from Doug/Andrew
- One from Wayne
Simrel Cycle
- Wayne: Much confusion with many projects; need to do a full evaluation and bring to the next meeting ... need to do better job on mentoring
- Committer Hangouts looking good (with help from Richard Burcher)
- EDP: "Releases" designed to be "major events", but for RT projects (Orion, Vertex) they want to release more often
- AI Wayne - Bug will follow
Usage of Non-Singleton like Guava
- bug 437107 Policy for shared non-singleton libraries such as Guava
- Marcel: Commented on the bug, enforcing everyone use one particular version of Guava doesn't make sense
- Adding "uses" constraints and import statements to "help" the runtime resolve properly is all we can do
- As specified in OSGi, and there's also a button in the IDE to add "uses" directives
- Recommend doing a "compatibility test toolkit" to ensure missing "uses" etc are discovered
- It's in the interest of consumers to have tested for compatibility and feed feedback into providers
- Adding "uses" constraints and import statements to "help" the runtime resolve properly is all we can do
- Eike changed Guava requirements for CDO (boradened it a bit), submitter confirmed that this solved the problem
- Wayne: But we have a PC Simrel requirement that one version of each 3rd party lib must be used (to reduce footprint etc) ... isn't that enough ?
- Marcel: Sometimes can't enforce exactly the same ... because eg newer guava introduced an 1.6 BREE but some projects required an 1.4 BREE
- Marcel: Commented on the bug, enforcing everyone use one particular version of Guava doesn't make sense
Oomph Update
- Doug played with it ... it does more than traditional installers --> defer to a separate discussion
- Might consider a special download link on the downloads page (because it's an alternative to downloading ZIP's)
- Mike M. would appreciate this, but would require good backing from the AC, PC and EPP
- AI All Review info on mailing list and comment there
Mentoring
- Krum signed up for 2 projects as 2nd mentors but never got any requests ... is this normal ?
- Wayne: For most of us, "mentoring" is just "answering questions"
- Locationtech may need some more pro-active help, they come from a very different community
General Topics
- Eclipse Infrastructure - git, Gerrit, Maven, Hudson, Bugzilla, ...
- CDT HIPP instance had some hickups this week (seemed like ran out of RAM)
- Denis: 10 HIPP's shared per server, 8 Gig for each ... did not notice anything out of the ordinary
- Denis: Projects can restart their HIPP in case of anything really problematic
- Denis: One problem is that lots of projects set up their git triggers to "every minute" that can cause quite some load on the git servers
- (probably 60 sec is the default!) Suggest polling every 5 minutes instead
- Doug: Would be great if Gerrit jobs could "trigger on push" rather than polling
- AI Thanh send out an E-Mail to projects
- Updates from the Board or the EMO
Action Items
- No new action items.
- Cleaned up old action items, see Architecture Council/Meetings/February 10 2011 for old stuff
- (old) Tim write up an initial wiki page with information for people to standardize on the tracing API
- (old) Martin revise the AC Wiki to make it easier to find the New Member Process. More links on homepage. More usage of categories.
- (old) Martin bug 315210 Make the AC mailing list open / moderated