[TangerineSDR] Tangerine Code Repo

Engelke, Bill bill.engelke at ua.edu
Tue Apr 14 12:54:03 EDT 2020


For what it’s worth, I am checking my code in daily (for the SBC part of the TangerineSDR) into github in my repository here:  https://github.com/AB4EJ-1/TangerineSDR-notes , because that’s what we put in the NSF proposal. If we should be mirroring or otherwise archiving in a second place, please advise, and I can start doing that. For the Central Control System, the CS team is still selecting & testing tools, so not a lot of code to check in yet.

-73- Bill AB4EJ

From: TangerineSDR <tangerinesdr-bounces at lists.tapr.org> On Behalf Of Aidan Montare via TangerineSDR
Sent: Tuesday, April 14, 2020 7:00 AM
To: TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr at lists.tapr.org>
Cc: Aidan Montare <aam141 at case.edu>; David Kazdan <dxk10 at cwru.edu>
Subject: Re: [TangerineSDR] Tangerine Code Repo

I'm interested to hear what you all come up with. For the low-cost PSWS that us from CWRU are working on, we have had our code very spread about at the moment. I'm currently centralizing it into a GitHub repository, though that definitely doesn't have to be a final solution.

To put in my two cents, I think the specifics of which tools are used is not always as important as communicating what is being used in an accessible, understandable manner.

On Fri, Apr 3, 2020 at 10:46 AM Tom McDermott via TangerineSDR <tangerinesdr at lists.tapr.org<mailto:tangerinesdr at lists.tapr.org>> wrote:
Hi John - thanks for clarifying the issue as 'code' not 'data' repository.

While understanding the sensitivity about the dropbox data repository changing terms, I think the
issue is not so difficult with a code repository.  If for example Microsoft were to change the
terms for github, one would assume there would be a period of time to gather one's code. Fortunately
with git that's easy to do, just git cloning the repositor(ies).  The size of the code repository would likely
not be so large that it's an issue.

Key needs in my view are:
1. Make it easy for everyone on the project to FIND the packages they need.
2. Make it straight-forward to revision control the code, and permit folks to use older tagged versions.
3. Provide a means where project contributors can review code, fix bugs, add new features, etc.
4. Provide a means for the original author to control and review before committing (i.e. accept / reject pull request).
5. Have well-known methods to clone, commit, and revision control code. (i.e. git or svn).

Niceties are:
6. The project to not have to run a server and update packages (including security) on a continual basis (i.e. the host does that).
7. Provide some hierarchy to the code repository to make navigation easier.
8. Provide email status updates and pull request notifications.

My view is that a Linux / debian focused community would find an obvious candidate here.

-- Tom, N5EG











On Thu, Apr 2, 2020 at 8:48 AM Dave Larsen via TangerineSDR <tangerinesdr at lists.tapr.org<mailto:tangerinesdr at lists.tapr.org>> wrote:
John

I agree with you, I just prefer not having a code monolith but several project specific locations.

As opposed to the TAPR GitHub we have now, which, as set up does not work well for development.  We may have a repository for code distribution later.

We have multiple client code producers and software consumers.  Interfaces for each are different and from experience with with the old SVN and the TAPR github experience differs widely.  What is easy for some is difficult for others.

And then we have the issue of keeping all the parts up to date and tested.

Dave KV0S



On Thu, Apr 2, 2020, 10:26 AM John Ackermann N8UR via TangerineSDR <tangerinesdr at lists.tapr.org<mailto:tangerinesdr at lists.tapr.org>> wrote:
It seems we have a couple of different discussions going on under a
non-inutuitive subject line. :-)

So this thread is to talk about where we store *code*, not data, for the
TangerineSDR and maybe broader PSWS-related projects.

I don't know enough to have a view as to what is the best approach.
What I do know is that TAPR has a github.org<http://github.org> account that's available,
and we also have a Linux VM hosted at a small but pretty decent hosting
company that we could install GitLab or whatever on.  Either of those
are available to the group if desired.

But we should decide on an approach now, as it seems various people are
developing or offering bits of code that we should deal with in an
organized way.

We should also consider whether hardware design documents should be
stored in the same manner, or with a different approach (as far as I'm
concerned a github-like repo works fine for my hardware stuff).

John


--
TangerineSDR mailing list
TangerineSDR at lists.tapr.org<mailto:TangerineSDR at lists.tapr.org>
http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
--
TangerineSDR mailing list
TangerineSDR at lists.tapr.org<mailto:TangerineSDR at lists.tapr.org>
http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
--
TangerineSDR mailing list
TangerineSDR at lists.tapr.org<mailto:TangerineSDR at lists.tapr.org>
http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org


--
Sincerely,

Aidan Montare
CWRU Class of 2021
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20200414/a4ea0720/attachment.html>


More information about the TangerineSDR mailing list