Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] AC slot at the Board meeting next week

Hi all,
Doug Gaff, Committer Rep at the Eclipse Board, has kindly volunteered to represent the AC at the upcoming board meeting next week in SFO. He asked me to compile a recent AC status update as well as a list of current challenges. Here's what I've come up with so far, based on the presentation [1] that I gave at the ESE members meeting. Your additional input, questions or comments are needed and most welcome, to make this the official AC point of view (rather than mine). This is a great chance for us to get heard at the Board!
AC Status:
  • Created some operational infrastructure (dormant status, bugzilla, wiki, doodle polls, mentorship info via portal)
  • Building up relevant Wiki contents on architectural as well as organizational issues
  • Gaining Community visibility and respect, getting initial requests (to act as a "judge")
  • So far, mostly focused on improving AC and committer communicatons / processes (with all the diverse Eclipse Projects, it's hard to see an overall architecture anyways, so the Process is the one commonality between all)
  • Starting some relevant initiatives: IPZilla "ask Mike" discussions, bi-weekly Committer info mail, architectural walkthrough
  • AC panel [2] at EclipseCon planned
  • "The AC maintains and evolves the Eclipse Platform Architecture through Mentorship, Consultation and Recommendations."
AC Challenges:
  • Insufficient active / PMC representation. The Bylaws say that first of all, 1 representative of each PMC should be on the AC but right now only few appointed members are really active. We're currently missing active, responsible representatives from the BIRT, TPTP, Tools, Eclipse and WTP PMC's. This makes it hard to make decisions that are to be executed on PMC level (such as the planning council does). Note that we do have active appointed members working under the Tools, Eclipse and WTP projects but that's not the same as a designated PMC representative. Currently, from about 50 AC members, only 5 are "really active".
Questions to the Board:
  • Money for common initiatives. Eclipse (and Galileo specifically) is in need of integration testing, accessibility implementation and testing, BIDI implementation and testing, usability testing and recommendations, and more "cross project" tasks. Many of the small projects cannot afford time for these efforts and/or don't have the expertise doing it properly (e.g. accessibility, globalization, BIDI). What does the Board think about the Eclipse Foundation employing personnel / consultants for such tasks, and have the money for these personnel collected from participating projects (similar to a multi-member marketing initiative).
  • LGPL dependencies (bug 246945). In order to be competitive, many projects need to pick up functionality from Open Source libraries developed outside Eclipse. Some of these are licensed under LGPL, which is considered incompatible with the EPL. While there is no term in the licensing that would prohibit using EPL and (L)GPL code together, the Foundation effectively prohibits LGPL dependencies as a matter of policy, even if it's just a hyperlink in a update manager to automatically install the LGPL dependency after the fact. The board is asked to reconsider this policy and/or come up with suggestions how EPL project frameworks can properly interface with LGPL code.
  • Serving a git Repository (bug 249745). git is an interesting alternative to CVS in terms of version control, but like all distributed vc systems (DVCS), keeping it IP-clean may be harder than with centralised systems such as CVS and SVN (because inappropriate content that's purged from the main repository may creep back in through synchronization with a slave repository). There may be technical measures to tackle the IP-cleanliness risk. Independent of whether the EMO webmasters have time to implement this, are we going to face legal issues with git? Can we have a "go" from the Board for such an initiative (e.g. for the e4 project, which is incubating, as a starter at first)?
  • Serving JIRA as an option (bug 253889). Atlassian JIRA, which is licensed free of charge to Open Source communities, has been requested as an alternative to Bugzilla. Bugzilla, however, is deeply entwined with Eclipse Foundation processes as well as its legal terms (e.g. contributions can only be accepted if submitted through bugzilla, thanks to the Website Terms of Use). While the need for and advantages of JIRA currently don't seem large enough to warrant migration, it should be discussed to what extent the legal entwinement of Bugzilla is set in stone or exchangeable by something more general such as "the Eclipse Foundation Issue Tracking Systems".
  • Copyright Headers for generated sources (bug 249959). How to treat Copyright Headers for generated checked-in sources? Should we just use the new ipzilla process for this discussion?
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

Back to the top