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 (Milestone Planning Meetings)
m
Line 9: Line 9:
  
 
=== Attendees ===
 
=== Attendees ===
- Heiko Behrens (records)
+
* Heiko Behrens (records)
- Jan Köhnlein
+
* Jan Köhnlein
- Knut Wannheden
+
* Knut Wannheden
- Moritz Eysholdt
+
* Moritz Eysholdt
- Peter Friese
+
* Peter Friese
- Sebastian Zarnekow
+
* Sebastian Zarnekow
- Sven Efftinge (moderator)
+
* Sven Efftinge (moderator)
  
=== Agenda ====
+
=== Agenda ===
- Retrospective (Post Mortem)
+
* Retrospective (Post Mortem)
- Process
+
* Process
- Infrastructure
+
* Infrastructure
<BREAK>
+
* <BREAK>
- Planning Helios
+
* Planning Helios
  
 
=== Retrospective ===
 
=== Retrospective ===
Line 30: Line 30:
  
 
*code ownership*
 
*code ownership*
- not a good idea, everybody agrees
+
* not a good idea, everybody agrees
  
 
*lack of time*
 
*lack of time*
- research project will improve this
+
* research project will improve this
- individuals should find their own ways
+
* individuals should find their own ways
  
 
*breaking changes / bad RC phase*
 
*breaking changes / bad RC phase*
- Maturity of framework will lead to more stability, needed flexibility
+
* Maturity of framework will lead to more stability, needed flexibility
- @stable/@deprecated annotation will remain, not automatic tests
+
* @stable/@deprecated annotation will remain, not automatic tests
- primary hooks will be revealed via documentation
+
* primary hooks will be revealed via documentation
- migration guide will inform user before a migration (on new version)
+
* migration guide will inform user before a migration (on new version)
- New and Noteworthy will be managed
+
* New and Noteworthy will be managed
  
 
*Xpand/MWE*
 
*Xpand/MWE*
- These components are quite important for the impression of Xtext, they act as "backend"
+
* 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.
+
* So far *just maintained*. Sven will take care of establishing milestone telkos and the like.
  
 
=== Process ===
 
=== Process ===
- we will continue to hold milestone planning meetings.
+
* we will continue to hold milestone planning meetings.
- we use bugzilla as our primary communication channel.
+
* we use bugzilla as our primary communication channel.
- we use target milestone to identify the current todos.  
+
* we use target milestone to identify the current todos.  
- we improve our commit messages (as already done lately)
+
* we improve our commit messages (as already done lately)
- conference calls will be hold on demand
+
* conference calls will be hold on demand
- outdated documents shall be removed or updated
+
* outdated documents shall be removed or updated
  
we now have an HTML page describing our process : [[http://www.eclipse.org/Xtext/developers/process.php]]
+
we now have an HTML page describing our process : [[http://www.eclipse.org/Xtext/developers/process.php]]
  
 
=== Infrastructure ===
 
=== Infrastructure ===
- We need to improve turn-arounds
+
* We need to improve turn-arounds
- Smaller workspaces (one for each Xtext, Xpand, MWE)
+
* Smaller workspaces (one for each Xtext, Xpand, MWE)
- dedicated target platforms
+
* dedicated target platforms
- .project settings for formatting, encoding, etc.
+
* .project settings for formatting, encoding, etc.
- Evaluation of SVN resulted in : seems to be too slow, we will stay with CVS
+
* 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
+
* 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
+
* find a way to avoid checking in generated code
  
 
=== Planning Helios ===
 
=== Planning Helios ===
  
** Wiki Document
+
*Review and Discussion of the [[Xtext/planning_0.8.0 Wiki Document]]*
- CleanUps
+
clean-up repository, wiki
+
refactorings API) will be handled during the milestones
+
usage patterns of guice have to be documented
+
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
+
  
- NewFeatures
+
* Removing dead artifacts in CVS and Wiki is important and will be done ASAP
Sven describes BaseLanguage nad how the viewpoints can benefit from it
+
* 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
  
- other topcis
+
*New Features*
many good ideas, priorisation will happen during milestone planning
+
* First focus : EMF Index
- No official Xtend customization in future, base language will supersede
+
* 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.
  
** Themes (over the year)
+
*Other Topics*
- Usability
+
* Create a bug for the annotation idea in order to collect use cases (Formatter, Warning, Validation once, datatype/fragment?)
-- UI Quality & Features
+
* many good ideas, priorisation will happen during milestone planning
-- API Quality
+
* ideas will go to bugzilla when need arises
-- Documentation Quality
+
  
- Performance & Scalability
+
* Project Plan Themes (over the year)*
 +
* Usability (UI Quality & Features, API Quality, Documentation Quality)
 +
* Performance & Scalability
 +
* Increase Applicability (Base Language, Grammar Features)
 +
* Clean Code
  
- Increase Applicability
+
* Project plan *
-- Base Language
+
* Sven will edit the project plan
-- Grammar Features
+
 
+
- Clean Code
+
 
+
- Project plan
+
=> Sven will edit the project plan
+
=> Annotation Bug (Formatter, Warning, Validation once, datatype/fragment?)
+

Revision as of 05:18, 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

  • 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