Elexis: un software libero
Elexis started as a community effort, and we welcome all contributors. Here’s your chance to get involved and help your fellow developers.
In June 2009 early users (medicial doctors) founded the Medelexis AG, to get professional support for their business critical application. Since then most of the development is sponsored/paid/organized by Medelexis, which runs also an internal bug tracking system (aka as Redmine).
To report bugs, please file an issue on one the the above source repositories (if are able to locate the bug) else use https://github.com/elexis/elexis/issues
Many of our discussions are done in the open, over email, and that would be the first place to look for answers, raise ideas, etc. For bug reports, issues and patches, see below.
If you wish to contribute code, please get acquainted with our SW
guidelines, which you find in the file
If you find any omission, typos, error or inaccurate statements in any of these documents please report them to the Elexis developers mailing list.
The release manager also maintains a ChangeLog for each repository and
branch.But as always the
git log command is the ultimate answer.
Elexis developers mailing list.
Medelexis AG runs an internal bug-tracking system redmine for Elexis bugs and improvements, where several hunderds bugs per year (since 2011) are tracked, classified and resolved.
Users and developers using the free Elexis, may post their problems github issue tracker or directly in the core/base repository, where the problem is rooted.
We really do try to keep bugs to a minimum, and anticipate everything you’ll ever want to do with Elexis. We’re also, not perfect. So you may have found a bug, or have an enhancement in mind, or better yet, a patch to contribute. Here’s what you can do.
Whether it’s a bug, enhancement or patch, send an email using email
Yes, please. The following steps are usually required
If you want to get your patch accepted quickly:
If you don’t know how to fix it, but can at least write a test for the correct behavior (which, obviously would fail), do just that. A spec is preferred to a fix.
If you want to work on a cool new feature, but not quite ready to submit
a patch, there’s still a way you can get the Elexis community involved.
We’re experimenting with using Git for that. You can use Git to maintain
a fork of Elexis that can keep up with changes in the main branch (tip:
git rebase), while developing your own changes/features on it.
You are free to license your new feature/plugin under any license you want, but
Did we mention Elexis is an open source project? In fact, when you install Elexis you get all the source code, documentation, test case and everything you need to use it, extend it and patch it.
Compiling Elexis from scratch can be a time consuming effort if you don’t follow the advise given here. If the procedures mentioned here don’t work for your setup please ask a question at Elexis developers mailing list before spending hours tracking down bugs.
Start with the Oomp based installer, as described under ch.elexis.sdk
The central repositories are:
Elexis uses the Jenkins continuous integration tool to perform builds, run tests and report back on problems when changes are made to the source code repository.
The care and feeding of the CI Jobs is the responsibility of the committers.
Two things we definitely encourage!
Obviously we won’t turn down patches, but we’ll love you even more if you include a test case. One that will fail without the patch, and run successfully with it. If not for our love, then think of the benefit to you: once we add that test case, we won’t accidentally break that feature in the next release.
We test using JUnit for Unit Testing and Jubula for GUI-Tests.
Yes, we do make typos, spelling errors and sometimes we write things that don’t make sense, so if you find a documentation bug, or want to help make the documentation even better, here’s the way to do it.
For simple typos and quick fixes, just send a message to the mailing list or log an issue in JIRA.
If you end up rewriting a significant piece of text, or add new
documentation (you rock!), send a patch. Making documentation patches is
fairly easy. All the documentation is generated from text files in the
doc/pages directory, so all you need to do is check it out from
Git/SVN, edit, and
svn diff to create a patch.
Our new web site elexis.github.com is based on GitHub pages and lives in the repository elexis.github.com
We use Textile as the markup language, it takes all of a few minutes to learn, it’s intuitive to use, and produces clean HTML. You can learn it all in a few minutes from the Textile Reference Manual. Also check out the Textile Quick Reference.
Syntax highlighting handled by Rouge. Use the
highlight tag to separate code sample from the rest of the
text and to tell Rouge which language to use. For example:
Have a look at existing documentation to see writing conventions. We use the Markdown syntax
This documentation uses Jekyll.