[TangerineSDR] Tangerine Code Repo

Aidan Montare aam141 at case.edu
Tue Apr 14 16:39:48 EDT 2020


Dave,

At the moment, our code is only for working with the fldigi-style doppler
shift measurements that we've been collecting at CWRU. I think that linking
to our work will make more sense once we've got our code working with the
tangerinesdr hardware (which we do hope to do).

I do think eventually it'll be good for the tangerinesdr page to include a
short reference to how it fits into the PSWS, and we'd be pleased to also
have a link to the low-cost version for those who are interested.

Best,

On Tue, Apr 14, 2020 at 1:58 PM Dave Larsen via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> Bill
>
> The only link in the tangerineSDR section of the website point to
> repository already.
>
> https://tangerinesdr.com/code.html
>
> Anyone that issues the command
>
>              git clone https://github.com/AB4EJ-1/TangerineSDR-notes.git
>
> Will get a complete copy of the current repository.  These can be used to
> replace the main git is necessary.  I suggest you make copies on a few
> trusted machines in your office.
> I will make one here. but I suggest that the main copy stay on github.com
>
> To update the repository as a user they simply in the local stored machine
> type
>
>       git status                       will list the difference between
> your copy and the github.com  (You must be in the git directory)
>       git pull                           will sync your copy with the
> repository  (You must be in the git directory)
>
>
> I have made a copy on my machine and plan to update is at least on
> Teamspeak nights.
>
> Dave KV0S
>
> On Tue, Apr 14, 2020 at 11:54 AM Engelke, Bill via TangerineSDR <
> tangerinesdr at lists.tapr.org> wrote:
>
>> 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> 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> 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> 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 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
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
>>
>>
>> --
>>
>> Sincerely,
>>
>> Aidan Montare
>> CWRU Class of 2021
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
>
>
> --
> KV0S - Dave Larsen
> Columbia, MO, USA
> --
> TangerineSDR mailing list
> 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/d533bb93/attachment.html>


More information about the TangerineSDR mailing list