Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[Chris Kuethe]

New module authors could contact the CGRAN admin(s) to be listed in the directory and if an admin finds a really interesting module they can reach out to the author to say "your project seems neat, could you send us a request to be included in CGRAN?".

A CGRAN admin would add them to the mirroring tool config (just a list of repo URLs), and the mirror tool could check the license status before updating - possibly by ensuring that {LICENSE,COPYING}{,.txt,.md} exists and contains some known text.

I'd be happy to help write some of the automation. I haven't yet tested what happens when I fork a repo and the upstream deletes their repo... does all my work go away?

On Mon, Oct 6, 2014 at 12:03 PM, George Nychis <address@hidden> wrote:

Interesting, Chris.  Thanks for that info.  The question would be, do we mirror everything?  It seems like that's a possibility.  It's nothing I think I could automatically set up.  I typically have left it up to the authors to decide given their software license.

On Mon, Oct 6, 2014 at 10:28 AM, Chris Kuethe <address@hidden> wrote:

It looks like github can mirror another git repo. It looks like mirrors don't update automatically; the docs suggest using a cron job to automate, so if the hypothetical grad student's repository goes away the CGRAN version could remain at the last published version.

On Mon, Oct 6, 2014 at 10:22 AM, George Nychis <address@hidden> wrote:

Let me add one more thing about CGRAN while we are still trying to narrow down how to handle this.  One reason I put CGRAN in place was to host code that might "disappear."  For example, students post it on university webpages and when they graduate, that hosting gets taken down.  Additionally, someone creates an account on some code hosting service, and the project later gets taken down.  That was the "archive" part of cgrAn.   I guess the more we talk about just linking to a bunch of things, I wonder if we will lose one of those initial goals.

On Mon, Oct 6, 2014 at 10:15 AM, West, Nathan <address@hidden> wrote:

On Mon, Oct 6, 2014 at 1:43 AM, Bastian Bloessl <address@hidden> wrote:
> On 10/06/2014 08:21 AM, Martin Braun wrote:
>>
>> but I don't really like this except as a temporary/transition solution.
>> Assume CGRAN really takes off and grows. Do you really want all OOTs out
>> there in a single repo? What exactly is their logical connection, which
>> would warrant them all being tied together in a super-repo?
>> This would require someone to keep updating the submodules, too, which
>> seems unnecessary.
>
>
>
>>
>> In the long run, I would assume people want to host their OOTs on github
>> (or similar services), and CGRAN would simply be a link to those.
>> As I said, during a transition time, we might want something else.
>> But submodules are messy, and I suggest not using them for this
>> particular application.
>
>
> Since, git 1.8.2 a git submodule can track a branch [1] (as opposed to
> pointing to a commit). That means that it is not necessary to update the
> submodules in the super-repo. A submodule is very similar to a pybombs
> recipe, a link to a repo and a branch.
> Most likely most of the repos (i.e. GNU Radio apps/modules) will be hosted
> at github or similar services. So nothing would change for the authors of
> the modules. (That's at least my understanding of the proposed solution)
>
>
> Best,
> Bastian
>
>
> [1]
> https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186


My $0.02 cents on CGRAN:

Having a directory of projects along with metadata such as author name
and contact, status, GR API version compatibility, etc along with a
source mirror and link to origin is really valuable. From this
perspective I like CCAN: they have a 'package' format so they can
parse and display that metadata in a convenient way on their web site
(for an example see http://ccodearchive.net/info/cpuid.html ). We can
use gr_modtool to either fill in a mod_info type file or request
authors put data in their README in a nice way. Then CGRAN can display
all of the project information, potentially provide a mirror, and
point to the original source.

I agree with Martin that the super-repo feels weird in the sense that
there is no shared history or relationship between the histories of
each project. If the goal is to make it easy to clone all projects at
once then pybombs almost does that already and it's very easy to
modify (actually it's probably a bug that pybombs fetch doesn't work
with --all). I do think it is convenient/useful to have a single
base-URI to get all OOT modules from assuming someone doesn't mind
paying for the bandwidth to have people constantly downloading OOT
projects. Also, what happens to a submodule if the origin disappears
(for example someone loses interest and eventually deletes their
github repo)?

Nathan.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
GDB has a 'break' feature; why doesn't it have 'fix' too?

--
GDB has a 'break' feature; why doesn't it have 'fix' too?