| [eclipse.org-architecture-council] raw minutes so far |
|
RAW MINUTES - DO NOT QUOTE OR PUBLISH Architecture Council – Chicago – June 28, 2006 JVM IssueProjects should tell their dependencies what the project’s JVM requirements are so that the dependency project can either support the project or tell the project NFW. Platform: if running on 1.4 JDT continues to work, if running on 1.5 you get additional features. Is Eclipse going to be a “1.4 application” and not move to 1.5? Is there a lock-in. Do we move beyond 1.4 in our source? The question is whether the APIs change from 1.4 to 1.5 – the source code underneath could, if desired, to change to 1.5. “Eclipse is a framework built around 1.4” How do we respond to “you are no longer cool because you are stuck on 1.4”? Dual APIs? 1.5 is a new language; 1.6 is not. Moving to 1.5 is not mandatory; execution can move; new plug-ins can move to 1.5 features. Our goal is to have both a smaller version and to support all the new features of 1.5 – the best of both. Someday. If new plug-ins need 1.5, (no gratuitous 1.5) go ahead and use it. Document it. Specify in manifest. Somewhere we should write up (on a wiki) what are the implications of changing to 1.5. Ed will draft the initial wiki page from the notes; Michael will help. Harm says that each project should have something on their own page about their position on 1.5; and point to the main central page. Multi-CoreWe need stuff for morons to help them understand how to be multi-core efficient. Common Build InfrastructureWhy are we (all the projects) doing our own specialized versions and specialized scripts? This makes coordination hard. Version number ranges: Ed talks about why he doesn’t want to do it manually. He has a script that computes it as part of his builder. People should use a common build infrastructure, but probably not require it. We should require certain interface/API things. RSS feed not that important to BIRT because they only pick up the milestone releases and their interfaces are not too tight. Reasons:
Kevin says “any automation for this stuff is good”. Don’t want to force too much conformity because that stops innovation; alternatively conformity in the base allows innovation higher up; innovation at the build system should not be being done. We should have a build teams get-together for social, technical, and requirements gathering. Ward offered that the Portland Eclipse team would be happy to arrange/host that. This gathering should be assembled with some sort of direction – what would that be? AC members should gather the problems their build teams are having, and the features their build systems have. Pain and Pride. Plus a wishlist. By July 20. Signed up: Bjorn, Harm, Kevin, Ed, Michael, Gary, John, John, David. Common shaped build results? |