[TangerineSDR] Tangerine Code Repo

[Dave Larsen]

Aidan

At the current moment we have little releasable software at this time.  I
plan to link to relevant repositories.  So people can find those projects.
Once we have a more complete system we may setup a release respository do
for users.

Do you have links you would like linked on the tangerinesdr website?

Dave. KV0S

On Tue, Apr 14, 2020, 7:01 AM Aidan Montare via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20200414/f528ee4b/attachment-0001.html>