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/Open Issues"

(→‎2007)
Line 1: Line 1:
 
Open Issues are Overflow items that have been proposed for a meeting, but that we ran out of time discussing. These items are pushed forward from meeting to meeting until we find time picking one up.
 
Open Issues are Overflow items that have been proposed for a meeting, but that we ran out of time discussing. These items are pushed forward from meeting to meeting until we find time picking one up.
 +
 +
= January 2009 =
 +
* '''[[Version Numbering Galileo Update]]'''
 +
 +
* '''Tom S: Project Proposals''' - RCP infra for getting them in easily vs. Wiki pages
 +
 +
* '''Tom S: Best practice for picking up I-builds''' - HTTP downloads are slow, installation cumbersome
 +
 +
* '''Christian Kurzke (TmL project, DSDP PMC)''' - recurring scanning of all code for IP issues
 +
 +
* '''Denis' [http://eclipsewebmaster.blogspot.com/2008/11/why-users-dont-bother-to-file-bug.html blog on dead bugzilla's].'''
 +
** {{bug|256660}} What are best practices to keep bugzilla alive and users interested, without taking away too much time from committers?
 +
** Should it be added as advice for mentored projects? Should the AC engage in the public discussion?
 +
 +
== Architecture Diagrams and Duplication ==
 +
 +
* '''Martin: Duplication''' - [http://www.eclipse.org/m2eclipse m2eclipse] and [http://www.eclipse.org/iam IAM] for Maven
 +
 +
* '''Martin - Architectural Pillars of Eclipse'''
 +
** The original AC charter included a task to draw/maintain architecture diagrams
 +
** With Eclipse based technology in so many and diverse areas, what is it that makes Eclipse Eclipse?
 +
** Better understanding our Community
 +
** '''The License''' - EPL, the big effort of being IP clean, and awareness of IP
 +
** '''The Development Processs''' - Eclipse Projects are meant to be open, transparent and release by a known plan. Maturity stages. Commercial Open Source. Bugzilla, Newsgroups, Mailinglists.
 +
** '''Java''' - the language of choice for most stuff although there are efforts to allow other languages as well
 +
** '''OSGi / Equinox''' - The component model for everything at Eclipse, differentiates us from other communities (Apache, Netbeans)
 +
** '''SWT''' - Although there are few (runtime) efforts without SWT or with AWT/Swing integrations, SWT still builds a strong foundation for most Eclipse/RCP Apps and with the e4 investment in using SWT for Eclipse in the Browser, it'll likely remain so.
 +
** Application Model - the "twenty things", mostly UI/IDE concepts already, see [[E4/Eclipse Application Model]]
 +
** Others? E.g. Plugin Registry, our tooling (JDT, PDE), provisioning (p2)? What is it that newcomers need to learn first about Eclipse?
 +
 +
* '''Martin: Architecture Diagrams''' -
 +
** Eclipse is growing rapidly, and it's getting ever harder to understand what projects are available, how they are interrelated and where there is duplication.
 +
** It was the original AC charter to create an architecture plan
 +
** Can we auto-generate an architecture diagram? - Some ideas:
 +
*** Scan the project's web pages and CVS Repository and build a semantic web
 +
*** Analyze the MANIFEST.MF dependencies in each project's repository HEAD, generate a dependency graph out of it and use some graph layout / clustering algorithm (could we allow interactive zooming into clusters?)
 +
*** Define some keywords, and ask each project use the Portal to pick keywords that are relevant for their project. Based on keyword association, have some graph auto-generated (clustered by keywords).
 +
** '''AI Martin''' ask on mailing list
  
 
= December 2008 =
 
= December 2008 =
−
* Martin: [[Architecture Council/F2F ESE 2008]] - thoughts in retrospect
 
−
* [https://www.eclipsecon.org/submissions/2009/view_talk.php?id=527 EclipseCon panel]
 
−
** [[Architecture Council/Ask the AC]] ideas for questions to discuss
 
−
** Who wants to participate on the panel, or be a moderator? - Bjorn, zx, Wayne, Mik, Markus, '''Jeff''', '''Ed'''
 
−
* [[Architecture Council/F2F EclipseCon 2009]] - Sunday afternoon - sign up and add to the agenda
 
 
* {{bug|256448}} API Tooling for extensions / How to treat propertyTester properties in ISV docs (best practice searched)
 
* {{bug|256448}} API Tooling for extensions / How to treat propertyTester properties in ISV docs (best practice searched)
 
* {{bug|167144}} "eclipse.common" bundle -- Bundle / Project granularity?
 
* {{bug|167144}} "eclipse.common" bundle -- Bundle / Project granularity?
Line 19: Line 52:
 
* EMO: {{bug|250317}} How to officially communicate Requirements (as per the board, dev process, IP policy...) to the PMCs, Project Leads, Committers?
 
* EMO: {{bug|250317}} How to officially communicate Requirements (as per the board, dev process, IP policy...) to the PMCs, Project Leads, Committers?
 
* '''RC - Roadmap Process''': [[RequirementsCouncilThemesAndPriorities]] - are we happy with it?
 
* '''RC - Roadmap Process''': [[RequirementsCouncilThemesAndPriorities]] - are we happy with it?
−
* '''PC''' - Richard Gronback: '''New [[Galileo]] Requirements''' from the Planning Council?
 
−
** Must do: Use only Published API by M6
 
−
** Must do: Provide basic Capability / Activity Definitions by M6
 
−
** Must do: Use Babel by M6
 
  
 
= 2008 =
 
= 2008 =

Revision as of 13:55, 15 January 2009

Open Issues are Overflow items that have been proposed for a meeting, but that we ran out of time discussing. These items are pushed forward from meeting to meeting until we find time picking one up.

January 2009

  • Tom S: Project Proposals - RCP infra for getting them in easily vs. Wiki pages
  • Tom S: Best practice for picking up I-builds - HTTP downloads are slow, installation cumbersome
  • Christian Kurzke (TmL project, DSDP PMC) - recurring scanning of all code for IP issues
  • Denis' blog on dead bugzilla's.
    • bug 256660 What are best practices to keep bugzilla alive and users interested, without taking away too much time from committers?
    • Should it be added as advice for mentored projects? Should the AC engage in the public discussion?

Architecture Diagrams and Duplication

  • Martin - Architectural Pillars of Eclipse
    • The original AC charter included a task to draw/maintain architecture diagrams
    • With Eclipse based technology in so many and diverse areas, what is it that makes Eclipse Eclipse?
    • Better understanding our Community
    • The License - EPL, the big effort of being IP clean, and awareness of IP
    • The Development Processs - Eclipse Projects are meant to be open, transparent and release by a known plan. Maturity stages. Commercial Open Source. Bugzilla, Newsgroups, Mailinglists.
    • Java - the language of choice for most stuff although there are efforts to allow other languages as well
    • OSGi / Equinox - The component model for everything at Eclipse, differentiates us from other communities (Apache, Netbeans)
    • SWT - Although there are few (runtime) efforts without SWT or with AWT/Swing integrations, SWT still builds a strong foundation for most Eclipse/RCP Apps and with the e4 investment in using SWT for Eclipse in the Browser, it'll likely remain so.
    • Application Model - the "twenty things", mostly UI/IDE concepts already, see E4/Eclipse Application Model
    • Others? E.g. Plugin Registry, our tooling (JDT, PDE), provisioning (p2)? What is it that newcomers need to learn first about Eclipse?
  • Martin: Architecture Diagrams -
    • Eclipse is growing rapidly, and it's getting ever harder to understand what projects are available, how they are interrelated and where there is duplication.
    • It was the original AC charter to create an architecture plan
    • Can we auto-generate an architecture diagram? - Some ideas:
      • Scan the project's web pages and CVS Repository and build a semantic web
      • Analyze the MANIFEST.MF dependencies in each project's repository HEAD, generate a dependency graph out of it and use some graph layout / clustering algorithm (could we allow interactive zooming into clusters?)
      • Define some keywords, and ask each project use the Portal to pick keywords that are relevant for their project. Based on keyword association, have some graph auto-generated (clustered by keywords).
    • AI Martin ask on mailing list

December 2008

  • bug 256448 API Tooling for extensions / How to treat propertyTester properties in ISV docs (best practice searched)
  • bug 167144 "eclipse.common" bundle -- Bundle / Project granularity?
  • bug 253889 JIRA vs bugzilla - just close it?
  • bug 249371 The new Eclipse.org homepage
  • bug 249745 Repository Best Practices (Subversive vs Subclipse); Mercurial, Git Bazaar -- bug 257706 now requesting git specifically
  • bug 246840 Jobs and ISchedulingRules - discussion concluded?
  • Items to move into IPZilla
    • bug 249959 Copyright Header in checked-in generated artifacts
    • bug 246945 Interfacing with Libs that are not EPL Compatible (mostly LGPL)

2008

How to start Releng?

Mentoring New Projects

  • What could be improved?
    • Webpage improvements: more pre-canned content for new projects (like Sourceforge)?

Top Ten Recommendations

Relationship to E4

  • E4/Pervasive Themes - Performance, Memory Footprint, Bloat (Boris' Blog), Concurrency
  • Invite E4 to present to the EAC?
  • E4 now has bi-weekly calls -- won't discuss E4 on the EAC unless asked / invited

Concurrency

  • Examples: bug 245573 comment 12 (Dali JPA Tools Deadlock, John CC'd to EAC); bug 246840 discussion about ISchedulingRule (saving project preferences)
  • What is causing issues?
    • work performed during class loading (Activator.start()) - unknown context, can run at unpredictable times
    • work performed in callbacks - unknown context, avoid synchronous callbacks
    • General recommendations: (e.g. avoid synchronous callbacks, avoid in Activator.start(), static initializers or Singleton getters) - a general recommendation could be to avoid performing work at unpredictable times, but that would recommend against lazy initialization in general
    • Does anybody have a well-working, consistent model on top of the current infrastructure?
    • Totally new concurrency mechanism as part of E4 ?
      • David Orme mentions DataBinding Realms and the Threads Considered Harmful blog which references Erlang message-based concurrence
      • Would it help to become more asynchronous under the hood, even if old APIs need to remain for compatibility?
      • Are there any other good known models for concurrency?
    • Better Javadoc ?
      • Example: ISchedulingRule.isConflicting() vs. ISchedulingRule.contains(), and how does it relate to RuleFactory and MultiRule?
    • Articles ? - John referenced the resource-deltas article

Eclipse Pain Points

  • Eclipse Pain Points

Other Ideas for Discussion

  • Mentoring Galileo: What could be improved?
    • Running each project's unittests with full Galileo installed; especially interesting for Performance tests
    • Don't duplicate work done by the Planning Council
    • 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 (Example: http://wiki.eclipse.org/images/8/86/Mylyn-Bug-Reporting-Example.jpg ). Do we want this for Galileo?

2007

  • Coordinated build (Ganymede) 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
Retrieved from "https://wiki.eclipse.org/index.php?title=Architecture_Council/Open_Issues&oldid=136872"

Back to the top