[TangerineSDR] Tangerine Code Repo

[Tom McDermott]

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