Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Architecture Council"

(Resources (from the "old" EAC for now))
Line 1: Line 1:
 
=Mission=
 
=Mission=
From the [http://www.eclipse.org/projects/dev_process/development_process.php#4_5_Councils Eclipse dev process]: ''"responsible for the development, articulation, and maintenance of the Eclipse Platform Architecture and ensuring the Principles of the Development Process <b>through mentorship</b>."''<br>  
+
From the [http://www.eclipse.org/projects/dev_process/development_process.php#4_8_Councils Eclipse dev process]: ''"responsible for the development, articulation, and maintenance of the Eclipse Platform Architecture and ensuring the Principles of the Development Process <b>through mentorship</b>."''<br>  
 
From the [http://www.eclipse.org/projects/dev_process/architecture-council.php EAC charter]: ''"responsible for the long-term technical health of the Eclipse platforms and frameworks (...) involves itself in inter- and intra-project architecture (...) <b>and open source process</b> (...) <b>through discussion during its meetings, mentoring and consultation</b>."'', so the EAC is involved in both technical and process aspects because the social and process structure of a project has been shown to have a direct impact on the technical quality of its extensible frameworks and exemplary tools.
 
From the [http://www.eclipse.org/projects/dev_process/architecture-council.php EAC charter]: ''"responsible for the long-term technical health of the Eclipse platforms and frameworks (...) involves itself in inter- and intra-project architecture (...) <b>and open source process</b> (...) <b>through discussion during its meetings, mentoring and consultation</b>."'', so the EAC is involved in both technical and process aspects because the social and process structure of a project has been shown to have a direct impact on the technical quality of its extensible frameworks and exemplary tools.
  

Revision as of 14:05, 25 August 2008

Mission

From the Eclipse dev process: "responsible for the development, articulation, and maintenance of the Eclipse Platform Architecture and ensuring the Principles of the Development Process through mentorship."
From the EAC charter: "responsible for the long-term technical health of the Eclipse platforms and frameworks (...) involves itself in inter- and intra-project architecture (...) and open source process (...) through discussion during its meetings, mentoring and consultation.", so the EAC is involved in both technical and process aspects because the social and process structure of a project has been shown to have a direct impact on the technical quality of its extensible frameworks and exemplary tools.

This role for the Architecture Council represents a new (revitalized?) role for the Architecture Council and thus there is not a lot of history to build on. The Council will be as effective and useful as we make it.

The membership of the Architecture Council is listed on the councils page of the main website, which also has an index to the meeting minutes of the "old" EAC.

Call Schedule

EAC conference calls are every month on the second Thursday at 8am Pacific, 11am Eastern, 5pm European time. A reminder email will be sent to the list in advance of the calls. The call-in number is on each Agenda page (usually the standard Eclipse Foundation Conference Bridge for Project Reviews, as per the MyFoundation Portal page).

The calendar is available in the following formats:
Ical.gifiCal,Xml.gifATOM News Feed,Html.gifHTML

Some interesting Items to Discuss at the EAC Calls

  • Ganymede build infrastructure - how to achieve continuous integration, unit tests covering the integration of all projects, and consistency across all projects
  • UI Consistency - when I'm not mistaken, the UI Guidelines are being reworked; how can we encourage projects to pick them up.
  • Remote Development - Theoretically, EFS should be the foundation on which workspaces can be put on remote machines, and I do see a lot of interest in this -- but practically, there are some roadblocks. It's a pervasive topic since most projects are not really EFS-aware yet. How to improve the situation?
  • Scripting, Macro Recording, DOMs - Another pervasive theme, if macro recording & playback is to be supported across an entire Eclipse based product, there need to be guidelines and APIs for projects to follow. It may be a multi-year multi-project effort but it may be worth getting it started.
  • Security - With the number of plugins aver growing, is there a threat of trojans nesting themselves inside Eclipse? Getting a trojan or virus-like plugin into Eclipse can be extremely malicious - from spying to impersonation up to data destruction. Is it a real threat, and is there something that could / should be done?
  • Project Model and Nested Projects - when developers lay out the directory structure on non-eclipse projects, they often use a tree where some directories represent projects. Those projects are "nested". This is also often related to the way the files are stored in a configuration management system. Unfortunately eclipse does not really support this real-world setup bug 35973, and this Blog by Alex Blewitt
  • Integrated bug reporting: Mylyn is providing a bug/error/enhancement reporting facility that will provide a flexible and product-configurable mapping between features, bundles and bug trackers bug 212209. Once done it would be good to discuss how best for EPP and other products to consume this (Example: http://wiki.eclipse.org/images/8/86/Mylyn-Bug-Reporting-Example.jpg )
  • Package visibility policies: New WTP Policy and bug 202711

Eclipse Architecture Recommendations

Top Ten Recommendations (work in progress)

Resources (from the "old" EAC for now)

How Do I Become A Member of the Architecture Council?

Architecture Council members come from three sources as per the http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf Bylaws]:

  • first, each Strategic Developer Member may appoint one member,
  • second, each Top-Level Project PMC may appoint one member (subject to the no-double-representation clauses of the Bylaws),
  • third, by nomination and election, the Council can recommend new members for appointment by the EMO (N.B. the Bylaws state that the Executive Director can appoint members to the Council; while remaining consistent with the Bylaws, this nomination and election provides an avenue for the Council to recommend such appointments)

At least once a year, the Architecture Council considers and elects new members. By convention, this happens in the first quarter of the year in advance of EclipseCon so that new Architecture Council members can attend the face-to-face meeting held at EclipseCon. The process is:

  1. Nominations are taken on the Architecture Council mailing list. Candidates must be current Committers on an Eclipse project.
  2. The chair calls for a vote whose duration is no less than one week.
  3. Voting is accomplished in the usual open-source manner, with each existing Council member voting +1, 0, or -1 on each candidate.
  4. Candidates must receive +1s from a simple majority of the existing Council members and not have any upheld -1s. Note that this requirement for a majority vote is a higher hurdle than the three +1s required for Committer elections, but this is by design: election to the Architecture Council is a sign of extremely high regard by the community.
  5. The chair passes the nominations and recommendations of the Council (as evidenced by their votes) to the Executive Director who then, at his discretion, appoints the new members to the Council.

What is the term of Architecture Council members?

Members appointed by dint of Strategic Membership have no term limits. Members appointed by the EMO are appointed to three year terms. Members' terms can be renewed any number of times through reelection.

Members who are unresponsive to the business of the Council (for example, if they do not participate in the vetting and election of new candidates) can be removed by a simple three +1s, no upheld -1s vote of the Council, or (in extreme cases) by the EMO.

Back to the top