Architecture Council/Minutes August 14 2008
|Meeting Title:||Architecture Council Monthly Meeting|
|Date & Time:|| Thursday August 14, 2008 at 1500 UTC / 0800 SFO / 1100 Ottawa / 1600 London / 1700 Berlin|
HTML | iCal
|Dial-in:|| (+1) 613.287.8000 (Ottawa and international) or|
866.362.7064 (toll-free North America)
- Sign up here if you want to get mentioned, since it's hard to catch all names during the call.
- Signed-up: Mary Ruddy, Darin Swanson, John Arthorne, Eugene Chan, Brian Fitzpatrick, Martin Oberhuber, Mik Kersten, Ingo Muschenetz, Bjorn Freeman-Benson, Richard Gronback, Michael Scharf, Andrew Overholt, Oisin Hurley, Markus Knauer, Tom Watson, Neil Haug, Ed Merks, Brett Porter, John Arthorne, Boris Bokowski, Steve Northover
- Tentative: John Duimovich,
- Regrets: Harm Sluiman, John Wiegand, Oliver Cole, Mike Wilson, Darin Wright
Agenda / Notes
- Feel free to edit!
- Rotating Chair Position for 1 year (term: 1 Aug - 1 Aug), election in June
EAC Role, and how to make it more relevant
- From the Eclipse dev process: "responsible for the development, articulation, and maintenance of the Eclipse Platform Architecture and ensuring the Principles of the Development Process through mentorship."
- From the EAC charter: "responsible for the long-term technical health of the Eclipse platforms and frameworks (...) involves itself in inter- and intra-project architecture (...) and open source process (...) through discussion during its meetings, mentoring and consultation."
- Mentorship can encompass many things - EAC as source for mentors, mentoring mentors
- "Pull" model: Allow adding email@example.com on CC on bugzilla for tough questions (rather than being active itself, the EAC is there to respond / mentor, and to identify issues)
- Cross-project Architecture Council Discovery and Reuse Activity: better a pull-model ("ask the combined wisdom") rather than a static page that tends to be out of date... or, come up with a process to auto-update the webpage?
- EAC Be a platform where pain points can be raised - but closer to committers than the Board. Suggest actions or create separate working group to work on things (Any pain points that come to mind?)
- Relationship of EAC compared to committer board reps? Don't duplicate board rep work. Probably delegate some topics to board reps?
- Mik: What kind of questions could go to the EAC?
- Ed: Assigned mentors should be on CC first, and if they are not able to resolve something they could escalate to the EAC - often it's got nothing to do with a specific bugzilla
- Ed: All projects should have mentors, even if graduated from incubation - some older projects don't have them
- Jeff: No, mentors were added to help projects through incubation (though some were incubated without a mentor)
- Martin: don't try to over-specify our scope, start trying to get topics by various means, since the main problem last year was lack of topics to discuss (which resulted in the much-hated what we're good for discussion)
- Oisin: in favor
- Jeff: duplication with cross-project?
- Martin: probably not very clearly defineable
- DougS, Ed: cross-project is something that matters to all projects; architecture council could be something that matters to "my project" but that I want to ask the Mentors
- MichaelS: "EAC bugs" in bugzilla as a Component
- Mik: "Cross-Projects" component already exists in bugzilla, could start using those more; though CC'ing cross-project worked
- Jeff: duplication with cross-project?
- Invite people to present architectural questions for discussion at EAC meetings
- MichaelS: The purpose of the EAC is still vague
- Martin: LPGL issue by Dave Carver
- Michael: That's not architecture?
- Mary: License questions are very relevant, would love to have that discussed here
- Jeff: Danger to comment if we do not have the right answer. Meta-statement is: knowing the bounds of EAC is important.. though we can give pointers
- Ed: Could turn the question into an architecture question - how can we build architecture that allows us to perform some work in a license-compliant way
- DougS: good idea, but we need to prioritize (controlled agenda)
- MichaelS: plugin dependencies, and how to reduce them - how to split into plugins
- Jeff: Agree, plugin granularity is important
- DougS: Catalog of Best Practices
- Boris: Would like to see more Articles on the Website (an "EAC Series" of articles, reviewed by the EAC) to raise the visibility
- Mik: Great idea, probably related to ui-best-practices group... "Top 10 Architectural Best Practices"
- Martin: Think about some fixed amount of time that we want to put into EAC stuff
- Boris to start collecting Top 10, Mik to help
- MichaelS to put Plugin granularity thing into an E-Mail
- What's making the monthly meetings attractive and interesting (or suck)?
- If meetings are short, and members gain something from the meetings (insights, news, experiences).
- EAC is also a platform for exchanging news, ideas, and best practices among the Mentors
- Bjorn - talking about what the EAC should do sucks
- Michael - F2F meetings sucked
- Ed - Complaining sucks
- Mik - Just like offering a UI Review in the UIBPWG, we could offer an Architectural Review, burden would be on the project to come up with materials
- AI Martin add the idea to our offering
- Boris: Needs people to put up an example, such that others can follow (Mik happy to sign up for Mylyn)
- We now got Google Calendar invitations. Responding to the invitations allows me to pre-fill the meeting attendee list.
- Nice: accumulate multiple public calendars on your own, by searching for "Eclipse" related calendars on http://calendar.google.com
- Hiding the call-in number? Bjorn: Reason was keeping Release Reviews restricted to members only
- Regular meeting date suggestions:
- (a) Keep 2nd Thurs of the month at 11am EST: not for Oliver Cole
- (b) 2nd Thurs of the month at 12 EST: not for Mary and Mik and DougS and DarinS
- (c) 3rd Wed of every month at 11am EST: not for Jeff, Mik, DarinS (Eclipse Planning) - Wednesday is generally bad
- (d) 2nd Tues of every month at 11am EST: not for
- Jeff proposes alternated meeting, in order to accomodate people with standing meetings (Tues and Thurs alternating)
- AI Martin put out the suggestion
- From the Development Process: "The Architecture Council will, at least annually, recommend to the EMO(ED), Eclipse Members who have sufficient experience, wisdom, and time to be appointed to the Architecture Council and serve as Mentors."
- From the EAC charter: "Members (...) are appointed to three year terms (...) Members who are unresponsive to the business of the Council (...) can be removed by a simple three +1s, no upheld -1s vote of the Council."
- Any inactive members to prune off the councils page? - Suggestion to add the Year of joining for appointed members, such that inactivity can be tracked.
- Have E-Mail proposals / elections like last year? Probably later this year?
- Dave Carver: profound knowledge in XML and web technologies, eager to help the development process
- Technical questions - DougS: Mailing List would be good
- MichaelS: Threading is a very important topic
- Ed: an interesting topic, should be discussed here
- Boris: perfect because JohnA is on the Council
- Martin: Using Bugzilla seems a good tool for such questions
- AI Martin fork out the ISchedulingRule question from below into a Bug for discussions
- A very technical issue, as a test balloon how that feels with the EAC
- Markus Schorn: bug 240888 - ISchedulingRule.isConflicting() vs. ISchedulingRule.contains() -- API Docs are there, but missing on the point how it is supposed to be used. How to write a contains() rule properly? How to use it with RuleFactory and MultiRule?
- Asking the combined wisdom of the EAC, how projects tend to be doing scheduling with IJobManager. Is the EAC the right platform for this, or where should this be discussed?
- Original problem was how to save Project Preferences properly:
- Need to run a job with a project-rule. Additionally in the job some project-preferences will be flushed. The flushing will potentially lock some resources, outside of the project!!.
- Problem 1: I have to know in advance, that the flushing of the preferences will lock resources. I need to look at its implementation to figure out the maximum of resources that will be locked. This is against information hiding.
- Problem 2: The rules are determined via IWorkspace.getRuleFactory(). It turns out that the rules I obtain from there can differ from call to call. This makes the situation worse in that I can run into an IllegalArgumentException, even if I obtained the rules for the job in the same way as it is done in the methods I am using inside of the job. How to use it properly?
- The bug is currently marked fixed, it was solved by taking a Workspace rule. But is this the best we can do?
- Implementation of the Job needs to call out to other (unknown) implementation through APIs, e.g. savePreferences. These may require new, different ISchedulingRules, but are not allowed to do so at liberty (for the sake of deadlock prevention).
- Should it be part of API Docs what SchedulingRules some API Call requires?
- Is there some different usage pattern to avoid the problem?
- ISchedulingRule#contains(): when a scheduling-rule contains another one, then a call to getJobManager().beginRule() for a contained rule simply has no effect. That means that by starting a rule that contains let's say all resources (that's compliant with the API) I can bypass any locking on resources in subsequent method calls.
- To get it right a rule should contain another rule only if it also conflicts with this rule. However, because isConflicting() has to be symmetric, I cannot contain another rule. The only way to do that is to use MultiRule (which gets special treatment in the job-manager).
- How to use RuleFactory and MultiRule properly?
- Dave Carver, Ed Merks: EPL to LGPL relation not clear, has been a topic for the board.
- GTK version of SWT links against LGPL'd lib? What can and can not be done?
- Is the EAC the right place for such questions?
- Jeff: The answer is, CQ the library, with "works with" or "requires".
- Ed: yes, but clients still struggle with building a working environment
- Jeff: Should try to address that with P2 and distribution technology
- MichaelS: Need an "Outside Eclipse" place for things with problematic licenses (antlr, emfatic, ... a single site)
- Jeff: somebody could do that, but the EAC should not promote that
- AI Martin create an EAC bug for this
- Boris to start a "top 10 architectural best practices" thread on the mailing list
- Martin to draft an E-Mail to eclipse.org-committers for review, inviting to put EAC on CC of bugs
- Martin to send E-Mail to EAC list as a reminder for "Architectural Walkthrough". Will propose this to the public only when we get one more project so sign up (in addition to mylyn) to make the review by putting together material (slideware, ...)
- MichaelS to draft an E-Mail about the "plugin granularity" idea, searching for people to lead the effort
- Martin to propose alternate meeting scheme on the mailing list
- Everyone to think about time commitments that can be made for "architectural things" at Eclipse
- Everyone to propose new members on the mailing list
- Martin to create bugzilla bugs for the ISchedulingRule and LGPL discussions