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 "Xtext/Meetings"

m (Planning Helios)
(Review and Discussion of the [Xtext/planning_0.8.0 Wiki Document])
Line 68: Line 68:
 
=== Planning Helios ===
 
=== Planning Helios ===
  
====Review and Discussion of the [Xtext/planning_0.8.0 Wiki Document]====
+
====Review and Discussion of [[Xtext/planning_0.8.0]]====
  
 
* Removing dead artifacts in CVS and Wiki is important and will be done ASAP
 
* Removing dead artifacts in CVS and Wiki is important and will be done ASAP

Revision as of 05:22, 6 August 2009

The calendar is also available in the following formats:
Ical.gif iCal,Xml.gif ATOM News Feed,Html.gif HTML

Meeting Minutes

Helios Planning Meeting 2009/08/05

Attendees

  • Heiko Behrens (records)
  • Jan Köhnlein
  • Knut Wannheden
  • Moritz Eysholdt
  • Peter Friese
  • Sebastian Zarnekow
  • Sven Efftinge (moderator)

Agenda

  • Retrospective (Post Mortem)
  • Process
  • Infrastructure
  • <BREAK>
  • Planning Helios

Retrospective

Each participant outlined his ideas about good and bad things that happened during the last year. The overall impression is that Xtext was great fun and a huge success. On the downside we agreed that we had a bad RC phase (too many changes) and we could further improve communication between committers (see process for actions).

Some other topics which arise were:

code ownership

  • not a good idea, everybody agrees

lack of time

  • research project will improve this
  • individuals should find their own ways

breaking changes / bad RC phase

  • Maturity of framework will lead to more stability, needed flexibility
  • @stable/@deprecated annotation will remain, not automatic tests
  • primary hooks will be revealed via documentation
  • migration guide will inform user before a migration (on new version)
  • New and Noteworthy will be managed

Xpand/MWE

  • These components are quite important for the impression of Xtext, they act as "backend"
  • So far *just maintained*. Sven will take care of establishing milestone telkos and the like.

Process

  • we will continue to hold milestone planning meetings.
  • we use bugzilla as our primary communication channel.
  • we use target milestone to identify the current todos.
  • we improve our commit messages (as already done lately)
  • conference calls will be hold on demand
  • outdated documents shall be removed or updated

we now have an HTML page describing our process : [[1]]

Infrastructure

  • We need to improve turn-arounds
  • Smaller workspaces (one for each Xtext, Xpand, MWE)
  • dedicated target platforms
  • .project settings for formatting, encoding, etc.
  • Evaluation of SVN resulted in : seems to be too slow, we will stay with CVS
  • local builds are now possible with Athena, this opens way to introduce server-side generation, promoting is still an issue with Athena
  • find a way to avoid checking in generated code

Planning Helios

Review and Discussion of Xtext/planning_0.8.0

  • Removing dead artifacts in CVS and Wiki is important and will be done ASAP
  • Refactorings in code will be done when we think they are neccessary
  • usage patterns of guice should be documented or streamlined (We should wait until migrated to Guice 2.0)
  • generator tests: amount of fragments stays the same (no reduced set of fragments)
  • evaluate: Antlr on the server to allow server-side test generation
  • logging: discuss with other project for better solutions, logging needs some improvements
  • Migrate to new versions of Guice, Google Collections and Antlr

New Features

  • First focus : EMF Index
  • UI Stuff based on Index : Navigation, Refactoring Validation
  • The big topic for Helios is the Baselanguage
    • Sven describes the general idea and how the viewpoints can benefit from it.
    • Knut already successfully prototyped the idea in his project.

Other Topics

  • Create a bug for the annotation idea in order to collect use cases (Formatter, Warning, Validation once, datatype/fragment?)
  • many good ideas, priorisation will happen during milestone planning
  • ideas will go to bugzilla when need arises

Project Plan Themes (over the year)

  • Usability (UI Quality & Features, API Quality, Documentation Quality)
  • Performance & Scalability
  • Increase Applicability (Base Language, Grammar Features)
  • Clean Code

Project plan

  • Sven will edit the project plan

Back to the top