[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipse.org-architecture-council] 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?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
