Architecture Council/Meetings/June 10 2010

From Eclipsepedia

< Architecture Council‎ | Meetings
Revision as of 17:01, 20 March 2011 by Martin.oberhuber.windriver.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Meeting Title: Architecture Council Monthly Meeting
Date & Time: Thursday June 10, 2010 at 1500 UTC / 0800 SFO / 1100 Ottawa / 1600 London / 1700 Berlin attention DST change
Html.gifHTML | Ical.gifiCal
Dial-in: NEW Canada 1-877-727-8553 toll free / 1-416-840-9801 caller paid
NEW U.S. 1-866-394-4146 toll free / 1-480-629-1624 caller paid
NEW passcode 428029063

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: Wenfeng Li Gary Xue
DTP: Brian Payton Linda Chan
DSDP: Martin Oberhuber TBD (DSDP-PMC)
Eclipse: Mike Wilson John Arthorne
Boris Bokowski
Modeling: Ed Merks Cédric Brun
Sven Efftinge
RT: Jeff McAffer Tom Watson
STP: Antoine Toulme Oisin Hurley
Technology: Gunnar Wagenknecht Wayne Beaton
Tools: Doug Schaefer
TPTP: Jonathan West
WTP: Tim deBoer Dave Carver
Neil Hauge
  • Regrets: Oliver Cole (standing conflict), Wenfeng Li (standing conflict)


Agenda / Notes

  • Feel free to edit, but not during the call!

Review of Last Meeting

New Topics

  • bug 315073 Denis: duplication of bits and mirroring
    • All-in-one ZIPs: could we recommend EPP packages + few downloads instead?
    • e4: EMF, Webtools, ...
    • Move from a all-in-one ZIP to an all-in-one Feature on a Repository (without duplication of bits)
    • Martin: any known issues with accessing a Repo (firewall, disconnected environment)...
    • Kim: Mirroring app can recreate the ZIP.. but it's not very well documented
    • Martin: Could e4 be moving ahead to "market" the idea of all-in-one-ZIPs?
    • John: Yes, after the July release.
    • Use-cases for other projects ... what requirements do they have? Would an all-in-one-feature be good enough?
    • Denis wants to clean up as much as possible in time for Helios... but all-in-ones can also be a longer term improvement
    • Kim: Eclipse Project is the biggest offender - 6 Gig per build! --> reduce the number of Platforms
      • No consistent (naming) convention for what-to-mirror vs what-not-to-mirror. Eg Denis suggested X-other on the bug.
      • Wayne: Just move to Archive makes it still available but not mirrored
    • Resolution: Looks like steps are good enough in the short term (plus bug 315073 discussion. After e4 release, showcase the "feature instead of zip", then mail projects asking to do the same.
  • bug 315210 Make the AC mailing list open
    • Ed: One idea would be expecting all AC members to be registered on the cross-project list; don't make the AC list "yet another" mailing list
    • Martin: Make AC list a moderated list? - typical answer would be "yes, good idea, please file a bug"
    • Mostly a psychological matter .. make us APPEAR more open. Boris agrees.
    • AI Martin follow up with Eclipse IT to make it happen. Moderators - Martin, Kim, Andrew
  • PMC Approval Lag
    • Doug S: Can be considered closed - was mostly an April Fool's Joke

e4 - current state of affairs

  • Boris: Making progress, release date unchanged (last Wed in July)
  • Please help out testing (and providing patches)
  • John: Try installing other Eclipse projects on top of e4. Some people are doing this already on e4-dev list
  • Looks pretty good already, quite usable for development (except occasional exceptions)
  • Tom Schindl been working on a forward compatibility layer to allow people take e4 features and have it running on top of e3.x (eg provide injection when running a part run on 3.x - allows same code to run on e3.x and e4)
    • Looks neat, might be something to look at in e3.7
  • Existing compatibility list - Boris: existing Wiki page with known problems. Could start such a page easily (Dan Rubel wanted to set that up)

AC Breakfast Followup

See Architecture Council/Meetings/March 25 2010 Breakfast

  • Martin: Follow-up action items from Eclipsecon Breakfast
    • Project Website Templates
    • Athena - Defer to Nick on issues found
      • Wayne: Would like to take the discussion more Meta; knows that Nick became interested in Tycho
      • AC should be making recommendations to the Community
      • Nick considered Athena a stop-gap measure from the beginning
      • Dave C: Much interesting Technology is around ... but it's still a bit of a Jungle
      • Wayne: Each has it's advantages, there may not be "the" answer. Buckminster, Maven, ...
      • Ed: Reproducable Buckminster builds for everything in Modeling. Cloudsmith interested in Buckminster for Platform. Although it's a Helios Requirement, hardly anybody can reproduce other projects' builds
      • Antoine: AC to set up "specs" for what a build tool needs to be able to provide?
      • What could be next steps for coming up with recommendations?
        • Dave C: Start with a Requirements Doc.
        • Wayne: Put together a Build Summit?
        • Antoine: Just putting all those guys in the same room won't work.
      • Kim: People won't agree on build technology. Helios Build Reqs may be a first step.
    • Build Users to write the Requirements.
    • AI Antoine and Dave C to start the Requirements doc
  • API Tooling
    • Produce an API report for all of Helios
    • Chris already did one (blogged it)
    • Point to the Must-do in the Portal

IP Log

  • Wayne: Had been looking through lots of IP logs - there is a misconception, especially about contributions, what should be in there.
    • Any contribution that is in the current codebase must be in that codebase's log. Even if 4 years old.
    • The easiest way to do this is to put the iplog+ flag on the attachment.
    • Don't iplog+ whole bugzilla's
    • Ed: If I use some other project, and that other project uses libraries: When I'm using them, I ought to file a CQ for using these
      • People use stuff from the Platform... technically, if you depend directly on a lib distributed by the Platform, you ought to CQ it
      • Wayne: Direct Reference to a 3rd Party Library requires a CQ.
      • Example: Ant - No need to CQ when depending on Platform API that uses Ant internally; but need a CQ if you're using the library directly (e.g. you have a Requires-Bundle or Import-Package statement for the library in your bundle manifest)
      • Most of us should have a CQ for JUnit! wtb: but don't panic; if you don't have one right now, don't worry about it. We'll be reviewing the policy post-Helios

IP Log information/help is available here.

AI All forward this to your Mentored Projects!

Items for next meeting

Regular briefing on the status of e4.

Old Topics

We need to reduce our bug backlog, by actually coming to a common resolution on some. Here are the most recent ones:

  • DaveC would like to discuss New Committer Guidelines; Scrum / Agile techniques
  • bug 285074 - Dave Carver - Hudsonbuilder and write access to the cvs / svn repo
  • bug 283745 - Maven Repository at Eclipse
  • bug 288393 - Denis - Bugzilla Best Practices
  • The art of project release naming - no bug yet ?!?

Action Items

  • (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) Tools and Tech PMC's to encourage incubating grandfathered projects find a mentor; mentorless projects due to AC members quitting or falling dormant
  • (old) Martin to add Eclipsecon meeting notes onto the wiki
  • (old) Mik to create initial "architectural walkthrough" material for Mylyn -- 1 wiki page not too large, send link to the mailing list
  • (old) Dave C work with Wayne on a "handbook" for project criteria for becoming a committer (referencing committer guidelines)
  • (old) Dave C come up with a document how to save build resources
  • (old) Dave C to try bugzilla UNCONFIRMED state
  • (old) Wayne to ask Sonatype about Nexus test installation
  • (old) Wayne to try doing a 3.6m2 API Report on Helios m2

Next Meeting