|[eclipse.org-architecture-council] Very raw notes from today|
Here’s a partial set of notes. I’m not much of stenographer, so please add your annotations and corrections. It gets passed the “existential angst” about mid-way through.
(intro – what should we talk about today?)
We got into the role of the AC again.
DS: We need multiple folks to step up and lead areas they’re interested in.
DG: I was asked to join to be a project mentor, but actual running a project issues could be covered elsewhere.
MO: Community gathering to discuss cross-project issues (naming, problems, perhaps cross-project arch questions)
EM: When I joined, we talked about Java 5.0. But we haven’t covered anything technical sense then.
MO: What do we expect from the arch council? We need to set the agenda ahead of time.
Mary: The agenda definitely helped ensure attendance at the last meeting.
DG: We definitely need to cover more technical topics.
DS: Maybe we need a project lead council?
DG: I think the Planning Council should be the project lead council. We should cover more than just Ganymede.
DS: Why didn’t the e4 team present to the AC?
Boris: Well, is writing an Eclipse plug-in difficult?
Several folks: Discussion about ease. Discussion about firefox plug-ins.
Boris: Well, one of the things we say on the platform team is that it’s hard to write an Eclipse plug-in, but maybe that’s an issue for some folks. That’s what motivated E4.
DS: Back to the original question, maybe the AC doesn’t have the respect yet.
Martin: I disagree, it’s the same leaders as elsewhere in the community.
Ed: Yes, as individuals we have respect, but we haven’t managed to glue this together into a respectable body yet.
DS: Right, one that people want to present ideas to.
DG: We need to stop calling ourselves dysfunctional.
Ed: Yeah, let’s just start covering interesting topics rather than reflecting on our role.
DS: So back to E4. Is it really just about the web?
Boris: Well, we feel like we’re responding needs of future software developers.
DG: Yeah, but not everyone needs Eclipse on the web. For us E4 is: reduce bloat, make it possible to dumb down the UI for some users, improve performance.
Tom: But don’t we have a backward compatibility requirement that makes dealing with bloat difficult?
Boris: Well, that’s a good question. The summit really needs to answer what the backwards compatibility requirements are.
DS: What is the bloat?
Boris: Well, we’re running out of permgen space. That’s one obvious sign.
(some discussion on the details)
Martin: We also have too many API’s. Some API’s can be deprecated, but some API’s are too widely used, but could be marked as “sub-optimal” (not recommended).
Boris: Yes, but the new API’s don’t always cover the corner cases.
Tom: Yes, but those corner cases are what causes the bloat.
DS: But, if we migrating people to a new major version, they will have to migrate.
Boris: This may require major breakage, though.
Martin: First, we should tag the good API’s and the corner-case API’s so folks know what we’re looking at.
Boris: Right, mark “recommended” and “non recommended” on API’s. This is the “20 things” discussion on the summit agenda page – the Eclipse application model. There’s another one, “architectural foundations” that should be relevant for the AC, too. Anyone want to help?
Martin: We should have a follow-on meeting next week to cover the “architectural foundations” topic prior to the E4 summit. Open call (beyond AC). Martin will send an invitation and will check about which number to use.
Everyone agreed, and we ran out of time.
Back to the top