Architecture Council/Minutes February 12 2009

From Eclipsepedia

Jump to: navigation, search
Meeting Title: Architecture Council Monthly Meeting
Date & Time: Thursday February 12, 2009 at 1600 UTC / 0800 SFO / 1100 Ottawa / 1600 London / 1700 Berlin
Html.gifHTML | Ical.gifiCal
Dial-in: (+1) 613.287.8000 (Ottawa and international) or
866.362.7064 (toll-free North America)
passcode 464440#

Contents

Attendees

  • Use the Doodle Attendance Tracking Poll to confirm attendance or send regrets for this meeting. See this message for how to use it. 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: Wenfeng Li Gary Xue
DTP: Brian Fitzpatrick Linda Chan
DSDP: Doug Gaff Martin Oberhuber
Eclipse: Philippe Mulet Mike Wilson
Modeling: Richard Gronback Ed Merks
RT: Jeff McAffer Jochen Krause
STP: Oisin Hurley Antoine Toulme
Technology: Gunnar Wagenknecht Wayne Beaton
Tools: John Duimovich
TPTP: Eugene Chan Oliver Cole
Joanna Kubasta
WTP: Tim deBoer Dave Carver
  • Signed-up:
  • Regrets:
  • No-Show:

Agenda / Notes

  • Feel free to edit, but not during the call!
  • I'm still working on this -- Andrew Overholt

Review of Action Items

  • Last meeting Architecture Council/Minutes January 15 2009#Action Items
  • (old) Martin to follow up with the m2eclipse and IAM projects regarding duplication
  • (old) Martin to follow up on Architecture Diagrams idea
  • (old) Michael to flesh out the Patterns idea and remind the EAC -- started Architecture Council/Top Ten Recommendations#Design Patterns, backed by EclipseCon tutorial proposals
    • While these show how well-known GoF patterns are applied in Eclipse, Michael's idea was more to find and describe new patterns which are specific to Eclipse
  • (old) Michael to draft an E-Mail about the "plugin granularity" idea, searching for people to lead the effort
  • (old) Mik to create initial "architectural walkthrough" material for Mylyn -- 1 wiki page not too large, send link to the mailing list (committed until end January)
  • (old) Mike to inform everyone when the IPZilla Legal Closed Group is ready to use
  • (old) All PMC's to encourage incubating grandfathered projects ask for a mentor (by filing an AC bug)
  • Dave Carver send links to Wiki pages which we might want to emulate for the AC Homepage
  • Mik to propose a date for demoing the Mylyn "report a bug" feature
  • Everyone review/edit the various Architecture Council wiki pages, particularly the Architecture Council/Ask the AC Panel/FAQ and Architecture Council/Links Collection. Add questions to the FAQ.
  • Ok green.gif Martin to schedule Architecture Council/Minutes API Deprecation 20080122 call
  • Ok green.gif Martin to schedule Architecture Council/F2F EclipseCon 2009 - Sunday 5pm-6pm
    • New Category markup allows us to tag other (non-AC) pages such that they show up under AC
    • Better organize the AC homepage: collect feedback... AI Dave send links to other Wiki pages for review to check which ones we might want to emulate, also, everyone can make suggestions / create mock-up pages for review.
  • Still open items moved to #Action Items

Administrative

  • IP/Legal Discussions: IPZilla closed group is up. In bug 214133, Martin asks whether having the link under the following areas of the portal is sufficient:
    • Committer on (xxx) -> IP Policy -> [pose] a question
    • Project lead for (xxx) -> IP Policy -> [pose] a question
  • PMC Representation on the AC - backup delegates, 1 attendee required
    • Backup still required for Tools PMC

News from the EMO & Councils

  • December Official Board Minutes not yet done
  • Mik: Are the EPP distributions "products"?
    • bug 261365 Board says No. No clear actions out of that, but it should be reflected on the download pages.
    • McQ: It doesn't matter what we label the EPP packages as... users just treat them as such, especially wrt JDT
    • Much Platform/UI bug triage work goes into things that should really be associated with other projects: a large portion of bugs doesn't have value!
    • Can we label stuff as "limited support" ?
    • Can we do something like Red Hat (with RHEL / Fedora distros)?
    • Jeff: Better highlight that there are supported offerings? Make it clearer what the support level is?
    • In Linux, are bugs reported against the distro or against upstream projects?
    • Martin: "Report a bug" wizard?
    • Boris: Why isn't there a "Services" company interested in creating a distro with a "report a bug" wizard and make money out of that?
    • Jeff: Make it clear in a positive way that stuff is available FOR FREE... and some bugs may be closed "WONTFIX"
    • Firefox and Openoffice are also treated as "products"...
    • Martin: "Expectation" discussion (to be held at planning council?) vs. technical "Low quality bugs" discussion
      • Mik: Help > Report this bug ... button in every distro that includes Mylyn been doing more harm than good so far
      • Kevin McGuire wanted to get bug auto-reported against Distro rather than component?
      • Boris: Platform UI tries to redirect bugs properly, not too big an issue for them
    • Martin: Windows 7 "Report a enhancement request with THIS component"
      • ... they set the expecatation like "We won't respond but your comment is valuable"
      • Mik: new "report bug" wizard allows to select any feature that has UI
      • Boris: "report bug" wizard could show a webpage with (paid) ads of companies for commercial support... commercial products could replace that by their commercial support page
      • Mik: Mylyn has an extension point for registering commercial support
      • AI Mik to propose a date for demoing the feature at EclipseCon
      • Doug Gaff (added after the meeting): I just want to summarize this by reminding folks that the EMO committed to 1) indicating that EPP packages are community support only and 2) providing links to Vendors that offer supported, commercial distros. Beyond this, it's in the community's hands.
  • StAC 090115 Minutes meeting for funding release train activities: following this meeting

New Topics

  • EclipseCon - AC meeting on Sunday before the conference (Mar 22) afternoon
    • Proposed StAC meeting 3pm-5pm including the AC, PC and RC; but we have some topics (like mentorship) not so interesting for the other councils
    • Official Architecture Council/F2F EclipseCon 2009 from 5pm-6pm, inofficial afterwards (Program Committee get-together after 6pm); want to have pizza dinner
    • Architecture Council/Ask the AC Panel: many questions are important for ourselves to understand and answer consistently
  • McQ - Eclipse Adoption and API Deprecation Policy
    • Platform clients have problems updating to newer Eclipse versions, in spite of remaining binary API compatible. Do others see this too?
    • How can inevitable migration effort (e.g. due to fixing semantic errors in API) be eased?
      • Tagging change / tools to detect change
    • How can we help clients become API-clean, and how can we help protect investment where API cleanliness is impossible?
      • Tools to report usage of non-API even in closed source
      • Allow clients to contribute unittests for code where they (have to) leverage internal non-API, in order to detect breakage early
    • How can we help clients detect usage of obsoleted features, and migrate to the new replacement feature more easily?
      • API Deprecation Policy / Soft deprecation tag
    • Is it reasonable to expect API-clean clients?
    • Dave Williams: Semantic differences are hard; in WTP, there are tools for scanning code and reporting back; would like to see PDE API Tools move into usage scanning as well
    • McQ: Want scanners on beyond-bundle-granularity to report usage. Should we do that between projects? Setup a database for the information?
    • Jeff: Low-fidelity / high-fidelity analyzers of usage
    • Martin: are we softening the "You must be API clean" story?
    • McQ: we should still be talking about "you must be API clean", but how can we live with reality? API does change. Take the low-level SWT event mechanism for instance. Can we tag non-API as "you're OK to use it"?
    • DaveW: at this point, we should be collecting information and then decide on what to do with the information.
    • Dave Carver: often, there is no way doing something without going "internal". How many people have actually requested something become API?
    • Report will also be good to find out what non-API should be made API
    • McQ: Formal deprecation policy?
      • Jeff: Setup another call for the deprecation thing? Start up simple and start a scanner for all of Eclipse.org
      • Darin: API Tooling currently working on scanners to discover references between plugins, generating report or dumping into a DB

Old items

Action Items

Next Meeting