[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for lo

From: Chris Kuethe
Subject: Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)
Date: Mon, 6 Oct 2014 10:28:41 -0700

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)?


Discuss-gnuradio mailing list

Discuss-gnuradio mailing list

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]