Dear all,
osmo-tetra has been without much progress (or the much needed gnuradio
3.7 support) for way too long time. I would like to see the project
move forward. There was a lot of good work by sq5bpf, but unfortunately
that work has happened in a fork outside osmocom.org.
Also, the code has various coding style issues and the commit messages
never consist out of a very short single line. To the benefit of other
reders and developers, that needs to be expanded a bit.
I would like to invite sq5bpf to become part of the Osmocom TETRA
proejct and would love to see a lot of that code go "mainline". Also, I
am open to eventual co-maintainership.
In order to facilitate this, I have moved osmo-tetra into
gerrit.osmocom.org. This allows us to have a structured community
review process (which I hope some of you will participate, particularly
our friend horiz0n) and vote on patches before merging them.
sq5bpf: I hope you have some time and energy to go the extra mile and
get your code merged and work together on a better osmo-tetra for
everyone.
I've started with a re-base of the sq5bpf/master branch on top of the
osmocom/master branch and pushed that to laforge/sq5bpf-rebase-20161218
>From a review through the patches, I believe we should create several
feature branches:
1) minor fixes and extensions
2) SDS related
3) voice related
Looking through the commits, I have several comments and questions
(mostly a result of the very terse commit logs, which is exactly a
reason why they should become more verbose):
* ppm support. Is this about some specific hardware / gnuardio source?
Do you expect it to break other receivers? How can this be
generalized?
edb7fce4ac8496ae1fe0a920bd49d7affcdd83c8 (simdemod2)
* simdemod2: should just be merged
cae3e848751d746431300dc65f7fc178f5e1bf35 (simdemod shellscript fixes)
* should be squashed in the above
e7be1e8672d48aebd1b6595a13c8bdd7a9037407 (codec tweaks)
* This neesd to be re-split into a patch series like the original, and
simply modify those original patches + README rather than adding a
separate set of those
6587739eb074741e64ad46777383a2257b28ea7e (correct tetra_upper_mac.c)
* what does it correct
* remove all the whitespace changes!
* adopt osmocom coding style throughout the code
* replace magic numbers with explanatiosn and/or #defines
* split into individual bug fixes and extension patches
593b9821e1267e19db9922fdd74525cc0f7c73c5 (fix sds crash)
* squash in whatever commit it fixes
8acfc998f0b7463f7ca3a303061611b5edbd072b (LIP / location system)
* remove all the whitespace changes!
* adopt osmocom coding style throughout the code
948ca3ebdde088ff68a8479364c12f24d8c91099 (add missing break)
* squash in whatever commit it fixes
538e8485637276a95216823770ede1e137279ae1 (better lip parsing)
* remove all the whitespace changes!
* adopt osmocom coding style throughout the code
* explain what exactly is better/extended in commitlog
bdf8c371b1d1b5662b031fdad0a3568129b90db7 (var fix)
* squash in whatever commit it fixes
a1fb5c348e6fb1102185131f38df8a8459a0cd83 (codec 64bit compilation)
* modify on top of cleaned up e7be1e8672d48aebd1b6595a13c8bdd7a9037407
4eeb3340ba75ad1a823dba8eb66031f80a5d5019 (gr 3.6 and 3.7 versions)
* copy+paste style development is rather ugly, is there no way to share
at least parts of the code and create a module that works with
multiple versions?
* if that's not possible, we should simply abandon all old code and
require 3.7 or higher.
a6b961a7554222dc3d9ce4ae25d859a645bbf109 (float2bits inside tetra-rx)
* the proper way is to have the related code once and use it in multiple
executables, rather than copying it around
6733e6c6edc2091b5e5c700cb26d7635dc08fac5 (move sds parsing to tetra_sds.c)
* should be squashed with original commits to avoid adding it to
tetra_upper_mac.c in the first place
72008e4418cd222cfe1846513cb8345709cdab78 (company-assigned tetra IDs)
* great, but avoid mixing whitespace change with functional changes
7145d09d5b236881edec659883f595f40fe38b88 (remove fifo)
* if the FIFO is no longer needed, this commit should be squashed with
those that introduce the FIFO support in the first place
59b036f59550a6d082b3d51635e381c4ef7e700b (add includes)
* squash with whatever commit that requires those #includes
6d38669f055b0355a71683a4b10fe3fea852b868 (fix d-setup parser)
* squash into commit that introduces the to-be-fixed code
Looking forward to getting this cleaned up and merged :)
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences. Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.
This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.
On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users. And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.
Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.
So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties. I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.
One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.
Another idea would be to split into a 'user day' and 'developer days'
format. This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software. The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.
Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.
One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?
What is the general opinion about this?
Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?
In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany. But I'm of course very happy if somebody wants to
host it some place else...
Regards, and looking forward to meeting you [again] in 2017,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
