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.
Repositories
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 git.lumiera.org, 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 git.lumiera.org. 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.
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://git.lumiera.org/lumiera/mob — typically onto a branch prefixed by your name.
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.htmlin 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 Development TiddlyWiki can be accessed read-only at Lumiera.org. -
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 Freenode.net
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.