Architecture Council/Meetings/August 13 2009
|Meeting Title:||Architecture Council Monthly Meeting|
|Date & Time:|| Thursday August 13, 2009 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)
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.
|TPTP:||Eugene Chan|| |
- Signed-up: John Arthorne, Neil Hauge, Mike Milinkovich, Mary Ruddy, Tom Schindl
- Regrets: Tim deBoer (conflict), Doug Gaff (conflict), Oisin Hurley (vacation), Bernd Kolb (travelling), Ed Merks (travelling), Andrew Overholt (conflict), Darin Swanson (conflict)
- No-Show: Chris Aniszczyk, Boris Bokowski, Adrian Colyer, Naci Dai, Sven Efftinge, Mik Kersten, Markus Knauer, Michael Scharf, Georg Schmidt, Mark Vandenbrink, David Williams, Darin Wright
Agenda / Notes
- Feel free to edit, but not during the call!
Review of Last Meeting
We need to reduce our bug backlog, by actually coming to a common resolution on some. Here are the most recent ones:
- Used to hide everything in the early days
- Now, if it's in .metadata already we don't hide stuff any more because it's hidden already
- In projects, we have .project / .classpath / .settings... recommendation to put stuff below there
- Recommendation should be to put stuff under a "." folder
- Should we migrate existing files that don't follow this convention to a newer convention?
- Resolution recommend procedure for new files.
- What to do with the old bug? - Comment and close
bug 283734 - zx - Crowdsourcing / doc best practices
- Moving end user docs from an HTML format in CVS to a Wiki: Mylyn quite successful, keeping documentation current
- Generate a "frozen" form (snapshot) from the Wiki
- Martin: in order for developers to update docs right when a new feature is implemented, they need to be comfortable with docs
- Dave C experience in WTP - lagging behind in docs: stuff changed and not updated in a couple years
- Technically: bringing existing docs into Wiki is not that hard... Dave C working on some XSL style sheets to populate initial pages
- zx moving PDE docs to Wiki.. could be a recommended approach, but need a "cookbook" for how to migrate. zx working on such a cookbook
- Martin: Is it possible to move from "frozen" docs to the online version? - Could add a hyperlink to each page
- Martin likes the idea of editing docs right from the context
- Tom: could we abandon the Galileo infocenter -- likely no
- Mylyn and WTP using Eclipse Wiki today... risk of name clashes? Likely not, Wikipedia has a lot more content
- Next steps: need a cookbook, AI Dave C, David Green, zx to work on
bug 283745 - zx - Maven
- Jetty had been building out of Maven, running into IP conflict because not building out of Eclipse CVS
- Blog posts from Jason around enabling Maven to better work with p2 / OSGi: has the time come for a Maven repo at Eclipse?
- What would we put in it? Maybe just the Orbit artifacts at first?
- Sonatype has new GPL'd product Nexus that we could probably make use of
- Allow projects to opt-in and put stuff into Maven as well
- Jetty started this train of thought, but we wouldn't want to do this for Jetty only
- Nexus can expose any kind of stuff as either Maven and/or OBR and/or p2 --> lot of value
- Tom S using Maven for UFacekit, because the project is going beyond Eclipse-only. Now creating his own Maven repo. Having a maven repo at Eclipse would be great
- AI Tom ask one of his committers to comment on the bug for guidance
- Wayne wants more people to comment on the bug - AI Wayne to blog about it
- Anybody against Maven? - No
- Any kind of political dimension from using Nexus? - No
- Martin strongly
- Wayne's concern is that we need to come to Denis with some proposal
- Mike wants to set this up like an action item for the foundation ... start with a feasibility study, ask for comments, etc.
- Tom: Maven may be particularly important for projects who don't target Eclipse only... like EMF, for instance
- We may need some documentation
- Resolution: - AC supportive of the idea
- AI Martin comment on the bug on behalf of the AC that we support this
- Next steps: gathering community, driving towards documentation for (a) what projects need to do, and (b) what the Foundation needs to do to get the service running
bug 283880 - Dave Carver - Project criteria for becoming a committer
- Some companies want to bring in committers quite quickly... for some member companies, the bar for being nominated is pretty low whereas for contributors not on an existing committing company the bar is much higher
- Martin thinks that personal conversation with contributors is necessary asking people to become a committer
- People who want to bring a project hosted elsewhere over to Eclipse want to know the implications of moving over
- Have a Foundation document as the overall guiding principle ... and recommend projects to set up their own guidelines
- Some documentation exists already... Wayne working on a new committer handbook
- Wayne: all projects have their own bar for coming in... criteria for initial committers on project creation is different than bringing in committers later on
- On DSDP PMC, we agreed to require a public record of 3 contributions at least ... in order for the PMC to be able and make a decision
- PMC has the final word on making the decision
- Wayne: difficult to quantify contributions. It's important to have some justification, and to have it public.
- AI Dave C work with Wayne on a handbook ... with reference to the committer guidelines
- Mike wants to make it clear that committers and contribution are welcome
- AC should remember projects that we are mentoring them
- ESE is coming up - please do submit talks and encourage others to
- bug 285074 - Dave Carver - Hudsonbuilder and write access to the cvs / svn repo
- roll-over to discussing offline
- The art of project release naming - no bug yet ?!?
- AC Bugzilla backlog
- Follow-up on Architecture Council/Bugzilla Best Practices - how to move on?
- Dave C AC should look at other Agile Principles can be employed (in addition to the Bugzilla practices)
- See also Architecture Council/Open Issues for overflow items that were not discussed
- News from the EMO and Councils ?
- (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
- (old) Tools and Tech PMC's to encourage incubating grandfathered projects find a mentor
- (old) Cedric, Tom talk to their PMCs about making AC representation official (can be 2 backup reps)
- (old) Martin to add Eclipsecon meeting notes onto the wiki
- (old) Dave Carver to blog about bugzilla best practices
- (old) Wayne to E-mail e.o-committers after that
- Dave C prepare a "cookbook" for bug 283734 Crowdsourcing Docs / WikiText --> DocumentationGuidelines, Dave's Blog
- Tom S ask Maven expert to comment on bug 283745
- Wayne to blog about Maven bug 283745 to get more comments
- Martin to comment on bug 283745 that the AC discussed and supports maven
- Dave C work with Wayne on a "handbook" for project criteria for becoming a committer (referencing committer guidelines)