Skip to end of metadata
Go to start of metadata

Meeting Details

  • Protocol: cds
  • Attendees:
    • cds
    • cmot
    • ima
    • msp
    • tig
  • Start: 13:20h
  • End: 15:40h



Our goals in restructuring the project are the following:

  1. Make it easier for us and for students to develop KIELER. Our current problems mostly come from the sheer amount of plug-ins KIELER is comprised of, and from the lack of a clear structure.
  2. Make it easier for third parties to use KIELER and help develop it.
  3. Improve our way of handling releases. The time it takes to decide to produce a release to its actual publication is way too long, unstructured, and simply not manageable.

The Structure of KIELER

Looking at our research, we basically work on three areas: Layout, Pragmatics, and Semantics. The new project structure should reflect that, but should minimize dependencies between the different components. (read: developers working on one component should not also need to work on another component.)

The new proposed structure is depicted in the attached PDF. The idea is as follows:

  • The General component contains core plug-ins. Whenever new functionality is required, it is implemented there and either released on its own, or bundled in its new version as part of a release of the other components. This component should be well covered by automatic tests and always be in a releasable state.
  • The second component is composed of automatic layout and pragmatics. Developers working in this area usually don't require anything from the third component.
  • The third component is composed of the rest (except for KEG, which may be in its own component and which doesn't change anymore at all). Developers working here checkout the repository of the second component, working against its latest release (captured in a tag in its repository). Thus, they don't work against the latest version of the second component, but rather against the latest released one.

ToDo for the Next Meeting

  • Think about whether all of this makes sense.
  • Check if KEG is dependent on Pragmatics. If not, move its dependency to the Layout component. Also, think about whether moving KEG to its own component would make sense. No work is done on it anymore.
  • No labels