The new emerging NLE for GNU/Linux

This section of the website contains resources for the active developers of the project. The content here may not be what you are looking for if you are a user.


The Lumiera sourcecode is maintained in a distributed fashion through a set of Git repositories. Each developer has his own repository, but usually developers are working on the same branches; e.g. you’ll certainly find the master branch in each repository. We are fairly liberal when it comes to giving people an account on, to allow publishing the individual developer’s work to public repositories. Just ask, maybe explain a bit what you intend to do.
→ browse our repositories online via Gitweb

Repository usage pattern

Developers work locally using Git repositories on their private PC. As a rule: check-in often, publish frequently. Each developer can pull from every repository, but has the right to push just to his own public repository at The ongoing work happens on dedicated branches. Developers might collaborate by using the same branches. Various working patterns are possible — just acknowledge with the others what you’re doing.

Eventually, changes and additions get picked up and reviewed by the core developer responsible for the layer or part of the application in question. This way, code gets merged to the master branch and pushed to the Lumiera master repository finally. Code seriously breaking existing unit or integration tests will be kept on hold, until problems are sorted out.

Mob repository

For small changes, and for the first contributions, there is a mob repository which is pushable by everyone. Just clone master, do your changes and push to git:// — typically onto a branch prefixed by your name.

Patches per eMail

You may send patches per mail. If possible, consider using git format-patch against a local clone of some Lumiera repository, because this vastly simplifies applying those patches on our side. If this doesn’t work for you, at least try to tell us the exact revision (SHA of the git commit) you’re basing your patch on.


Ichthyo also maintains a backup copy of the primary Repositories at Github
In case everything else fails, you may fork there as well.

Technical Documentation

  • semi-final detail documentation can be found in the Documentation section

  • for work-in-progress on the “Proc-Layer”, Ichthyo uses an embedded TiddlyWiki in the source tree. There you’ll find extensive documentation about internal concepts, design reasoning and UML diagrams. Just point your browser at the file wiki/renderengine.html in your local source checkout. Local Modifications, additions, corrections are welcome and can be fed back as patches or git checkins. A fairly recent copy of this Renderengine-Wiki can be accessed read-only at

  • you might want to have a look into the generated API documentation — especially when interested in some concepts, subsystems or components, check out the file-level documentation of the corresponding primary header files.

  • The issue tracking system (Trac) provides several Query-reports. Especially the report »recently changed« might give a good feel about currently ongoing activities.

  • feel free to ask on IRC!

Development Process

The Lumiera developers favour an open, semi-formal development style.

IRC Developer meetings

We try to “meet” at least once every month in our IRC channel #lumiera on
Depending on the number of participants and topics to discuss, these meetings are more formal or informal. Everyone is welcome → more about dev meetings.

Design proposals

For proposals, design plans and basically everything requiring some kind of discussion and agreement, we have the more formalised Design Process: Everyone can write an RfC, using our standard template. Typically we expect each proponent to participate in some way in the implementation of such a proposal. These RfC entries will be discussed at the developer meetings and finally accepted or rejected.

Unit tests

Code should be structured in fine granular components. Each component should expose a clearly defined contract, and this contract should be covered by unit tests — preferably before writing the implementation. Besides providing a safety net, unit tests also serve to document the intended usage.