osmo-tetra: Add DMO Code

historical

Hi Jannik,

On Fri, Jan 13, 2017 at 12:10:57PM +0100, Jannik Jürgens wrote:
> I currently writing my masterthesis about TETRA. For this, I am
> currently writing my master thesis on TETRA. For this the support of DMO
> is necessary. Another student had already implemented a rudimentary DMO
> receiver (based on the Osmocom code) in his thesis, which I now develop
> further. I would like to add this code to the Osmocom project as a new
> branch so that other people can participate.

Thanks for reaching out, and I'm looking forward to see DMO support in
the project!

Unrelated to your work, Sylvain has recently published some DMO related
wokr in the users/tnt/dmo branch.  We had a quick conversation about DMO
at 33C3 and he started right away to modify the demodulator/decoder from
the osmo-gmr project.  Have you seen that yet? Did you play with it yet?

In general, the goal should be to not only have yet another branch, but
to actually take it all the way to actually get it merged.  I understand
of course that as a student your primary goal is your thesis, but I have
seen a lot of "fire and forget" style "contributions" of students
before.  Please take the extra effort and go through review cycles until
your code is merged.  Having it somewhere in a branch is nice, but in
the end there will be dozens of diverging branches, with different
featureset, unable to reconcile.  This is clearly not the collaborative
Free Software development process :)

> I was unsure, based on which branch I should develop the code, but I
> decide for the laforge / sq5bpf-rebase-20161218 branch, because this is
> most useful for my purpose. I hope this is okay and doesn't lead to
> chaos. When trying to create a new branch and commit this, however I get
> an error message:

It would be preferable to develop related changes based on master.  The
sq5bpf code (as you can see by recent mails on the list) is more
experimental and (as can be seen from only looking at coding style)
unfortuntely needs some more clean up before it can be merged.

Please don't get me wrong.  I love it if people work one features and I
want to encourage all kinds of contributions.  But at the same time, we
have to maintain some degree of architecture and code quality.

Even 'sq5bpf' himself has stated that he didn't officially submit his
code as he doesn't think his code is ready for getting merged.  So if
you base your code on that, you introduce a dependency that might make
it harder to get your code merged eventually - or at least a dependency
on something outside your control.  But it's of course your choice.

> $ Git push origin jj / dmo
> Error: no DAV locking support at https://git.osmocom.org/osmo-tetra/
> Fatal: git-http-push failed Error: Error sending some references to
> 'https://git.osmocom.org/osmo-tetra'

the http and git protocol is for check-out only.  In order to commit,
you need to use a ssh+git URL and have your ssh public key resgistered.
To do so, please send it to me.  you can then push your code into a
branch.

> Unfortunately, I have not found instructions, who is at Osmocom allowed
> to commit code or how the process works. Can you help me with this or
> send me a link, where I find the appropriate information?

This depends on project by project basis.  In the cellular
infrastructure projects we have recently started to use Gerrit (see
http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit) but
this has not been adopted by all projects, particularly not those that
haven't seen much activity in past years like osmo-tetra.

However, I'm tempted to migrate osmo-tetra over to gerrit.  What do you
think?  Have you worked with gerrit before?

Unless we introduce gerrit, you can push code to a user-branch to the
repo, but from there you will have to use git send-email to send patch
series for submission here to this list, where changes will be reviewed
and then hopefully merged.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)