3rd party software (was comedilib question)

On Mon, Aug 25, 2008 at 10:43 AM, Dan H.
[email protected] wrote:

On this note, but slightly tangential, there are a bunch of third party
gnuradio plugins that are not being kept up to date and even no longer work
with gnuradio without significant changes. (E.g., top block vs flow graph).
Do you think we can create space in SVN somewhere for the updated versions
of these codes? I’m thinking about gr-ucla and maybe the BBN 802.11 stuff as
well.

There are two issues with this.

The first is that the software you describe seems to not have a
maintainers, and thus the bit-rot has set in. Having it in our SVN
doesn’t change anything.

Secondly, with a few very rare exceptions, the host software in our
repository has all of its source code copyrights assigned to the Free
Software Foundation. So, even if we had committed maintainers for
this 3rd party code, we’d need to get copyright assignments from the
original authors.

That said, I’d be happy to help you and/or others to get them up to
date. Since they are all GPL, there is no issue with hosting them
somewhere else and patching them up to be current. We could even have
a wiki page dedicated to these efforts.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

Johnathan C. wrote:

There are two issues with this.

That said, I’d be happy to help you and/or others to get them up to
date. Since they are all GPL, there is no issue with hosting them
somewhere else and patching them up to be current. We could even have
a wiki page dedicated to these efforts.

I’d like to bring this back up. I think Dan is poking at something that
has really bugged me for some time too. I think there is a ton of GNU
Radio code floating out there that is potentially extremely useful to
other people, that is never adopted in to GNU Radio because the barrier
of entry of code into GNU Radio is extremely high.

Copyright assignments, developer branch, QA code, following conventions,
awaiting approval, hesitation of maintainers to let in code they’re not
familiar with… let’s face it, getting code in to GNU Radio if it’s not
a bug fix is a serious hassle that not everybody has time for. I
completely understand the reason for all of the above, but it’s the
reason why we need something for 3rd party software.

There have been tons of postings to the list about projects people have
done, that maybe only work with a certain snapshot of GNU Radio. I
think this is OK. For example, someone might want to work with the
gr-ucla code and they don’t care about new enhancements to GNU Radio
which make it unworkable. They check out a snapshot, and gr-ucla code.

So, you’re probably thinking: OK so why do we need 3rd party support,
they can just check out the gr-ucla code and then an old version of GR
and be happy. Well… if they went to update that gr-ucla code they
need to contact the UCLA people. Whereas if there was a third party
repo, they could just makes changes for example, upgrading it to work
with the current GR release.

Additionally, 3rd party support is a great way to gather code for
someone to look at what else is available out there. For example, there
was multi-path code someone posted a while back that they had to go
through some hassle to setup their own server to host it. That server
is likely down by now. If there was some additional repo they could
commit it to, we’d have it right here right now to work from, and so
could other people.

Also, I spoke with Kyle that he revamped some of the OFDM code and has
been trying to get it in to GR but has had problems with either contact
or acceptance of his changes. I’m sure the code could definitely be
used by others… I think there should be somewhere that Kyle could
upload his code and let others use it.

Maybe an additional SVN is what we need. Maybe a GIT repo. A wiki so
that people can provide some information about their code. We need
something. I don’t care of its officially supported by GNU Radio or
not, but I think it would certainly benefit the GNU Radio community.

  • George

On Tue, Sep 09, 2008 at 02:21:19PM -0400, George N. wrote:

I don’t care of its officially supported by GNU Radio or not, but I think
it would certainly benefit the GNU Radio community.

  • George

I’ve just registered cgran.org – the Comprehensive GNU Radio Archive

Please let me know when you’ve finished implementing it, and I’ll
point the DNS records to it.

Eric

Just putting my 2c in: I also think it’s a great idea to have a 3rd
party
repository, independently of license, the existence of a maintainer etc

The main gain of this would be a demonstration of the strength of
GnuRadio.
Here’s what I mean:
Today, if someone who has no clue about what GnuRadio can do visits our
wiki
and downloads the latest stable version, then has a look around to see
what
it can do, will conclude: GnuRadio is a bunch of infrastructure stuff
(sources, sinks, processing blocks such as filters etc, a scheduler) and
the
“examples”, which are very useful to flatten the learning curve, but are
pretty basic.

Instead, let’s say he has the option to download also the 3rd-party
package
(in Ubuntu they call it the Universe and Multiverse repositories), which
might or might not be GPL, and does tons of stuff, like (partially) GSM,
(partially) WiFi, (partially) bluetooth, (partially) RDS
I think it would make a much stronger point of the breadth and strength
of
the GnuRadio developer and user community, as well as about the
potential of
the software itself…

Kind regards
PS Jonathan is right, it’s only an idea until someone implements it
PS2 Thanx to Eric for already registering the domain

On Tue, Sep 9, 2008 at 21:04, Johnathan C. <

On Tue, Sep 09, 2008 at 11:45:15AM -0700, Eric B. wrote:

people can provide some information about their code. We need something.
I don’t care of its officially supported by GNU Radio or not, but I think
it would certainly benefit the GNU Radio community.

  • George

The slightly longer response:

I think these are all great ideas, and I think they’d be a valuable
contribution to the GNU Radio community. CPAN (The Comprehensive Perl
Archive Network) and CEAN (the Comprehensive Erlang Archive Network)
are but two implementations of similar ideas. CPAN has been wildly
successful and is part of what has driven Perl’s popularity.

If you want to try git – or whatever – please do, and keep us
informed!

Eric

OK, since this is for “us,” and us being the GNU Radio community, this
should be up for discussion with everyone here.

What would people like to see? Do people have preferences in version
control systems? It seems as though most people familiar with GNU Radio
are already familiar with SVN, so would sticking with SVN be a good
idea?

What do people think of trac+SVN for a website and documentation of
code/projects?

Eric has already provided us with a domain name, and I’m 100% sure CMU
could host whatever we want… I just want some feedback from the
community since it’s for you (and me ;)) and it should be something
people want to use. Once we come up with a basic design and policy, we
can move forward. I just don’t want to pop up with some website and
system that nobody likes, and have to then have this discussion and
reimplement.

Thanks!
George

On Tue, Sep 9, 2008 at 11:21 AM, George N. [email protected] wrote:

Maybe an additional SVN is what we need. Maybe a GIT repo. A wiki so that
people can provide some information about their code. We need something. I
don’t care of its officially supported by GNU Radio or not, but I think it
would certainly benefit the GNU Radio community.

Open source software and infrastructure grows by the volunteer efforts
of those who find ideas important enough to go implement.

What you describe is an excellent idea, but will remain only an
expressed wish, until it is implemented.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 11, 2008, at 1:14 PM, George P Nychis wrote:

What do people think of trac+SVN for a website and documentation of
code/projects?

Eric has already provided us with a domain name, and I’m 100% sure
CMU could host whatever we want… I just want some feedback from
the community since it’s for you (and me ;)) and it should be
something people want to use. Once we come up with a basic design
and policy, we can move forward. I just don’t want to pop up with
some website and system that nobody likes, and have to then have
this discussion and reimplement.

My impression is that SVN+trac is working pretty well. My experience
with git has been everything but positive; maybe because I still
haven’t found that simple, elegant reference that explains it well,
but I’m just not a fan. Plus it would be nice to keep the same model
as the existing repo so that the checkout and build process is as easy.

Just my 7c :).

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjJg0sACgkQy9GYuuMoUJ7M9ACggVcqrdxroGJalRlSM2LYxic/
CpUAnA1rO4w4eQUXRnOaQxmzp+tnNvZw
=v2QF
-----END PGP SIGNATURE-----

Hi Community,

I want to share my 2 cents too,

George N. Wrote:

I agree, svn+trac is the way to go here. It’s what everyone is already
familiar with, and it works great.

I agree too.

I was thinking that the SVN structure should be something like:
/
/project_name
/project_name/trunk
/project_name/tags
/project_name/branches

I think, since it has not been created yet, careful structure should be
followed. We should seek Eric and Johnathan advices.

and then everyone has read access to everything, and commit access is
given to individuals working on > a project, or pretty much anyone who
wants it. I just don’t think we can leave it anonymous commit.

Ok, but I think the documentation should be leaved to anonymous commit.

Then, there is a mandatory project summary page for each project. It
needs to include basic
information like the platforms it runs on, the version of GNU Radio
needed, and any other additional
dependencies with a brief description of the project. Probably some
maintainer information too.

I think we should add project references, snapshots, Bugs, Todo,
documentation, Project voting, License…etc fields too. We should
investigate “SourceForge” or any other similar web site to import
useful
features from it.

Best Regards,

Firas


View this message in context:
http://www.nabble.com/3rd-party-software-(was-comedilib-question)-tp19148615p19450726.html
Sent from the GnuRadio mailing list archive at Nabble.com.

My impression is that SVN+trac is working pretty well. My experience with
git has been everything but positive; maybe because I still haven’t
found that simple, elegant reference that explains it well, but I’m just
not a fan. Plus it would be nice to keep the same model as the existing
repo so that the checkout and build process is as easy.

Just my 7c :).

Thanks Dan!

I agree, svn+trac is the way to go here. It’s what everyone is already
familiar with, and it works great.

I was thinking that the SVN structure should be something like:
/
/project_name
/project_name/trunk
/project_name/tags
/project_name/branches

and then everyone has read access to everything, and commit access is
given to individuals working on a project, or pretty much anyone who
wants it. I just don’t think we can leave it anonymous commit.

Then, there is a mandatory project summary page for each project. It
needs to include basic information like the platforms it runs on, the
version of GNU Radio needed, and any other additional dependencies with
a brief description of the project. Probably some maintainer
information too.

  • George

George P Nychis wrote:

I was thinking that the SVN structure should be something like:
/
/project_name
/project_name/trunk
/project_name/tags
/project_name/branches

What does everyone think about user directories?

/
/projects
/projects/project_name
/projects/project_name/trunk
/projects/project_name/tags
/projects/project_name/branches
/users
/users/gnychis

etc…

Hi,

I thought I’d just drop some lines too (without actually being helpful
:).

On Fri, Sep 12, 2008 at 12:13:26AM -0700, Firas A. wrote:

I was thinking that the SVN structure should be something like:
/
/project_name
/project_name/trunk
/project_name/tags
/project_name/branches

I think, since it has not been created yet, careful structure should be
followed. We should seek Eric and Johnathan advices.

Sorry for being such a nuisance, but this is not exactly what I’d wish
for it to be. 3rd-party repos should not be clones of the ‘master repo’
concerning rules and structures. Of course, minimum standards for these
repos need to be set (e.g.: the ability to compile with a specified
snapshot without major modifications; and of course the coding
guidelines). But if the barriers for new people to contribute are to be
lowered, a small amount of anarchy will need to be tolerated if we want
to get close to the maximum creative channel capacity.

and then everyone has read access to everything, and commit access is
given to individuals working on > a project, or pretty much anyone who
wants it. I just don’t think we can leave it anonymous commit.

If people have to ask for permission to do anything, in many cases they
won’t do it. Becoming a 3rd party developer on CGRAN should consist of
an on-line registration IMHO (including some kind of write-access).

documentation, Project voting, License…etc fields too. We should
investigate “SourceForge” or any other similar web site to import useful
features from it.

There must be a free web-based 3rd-party-repository-manager out
there, although I haven’t seen one with SVN support or similar.
I’ll keep my eyes peeled as well. Personally, I don’t like any of the
existing C*AN contribution methods (upload forms, email your package
to XXXX…).

Cheers,
Martin


Martin B.
Institut fuer Nachrichtentechnik
Universitaet Karlsruhe

http://www.int.uni-karlsruhe.de