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 <gnyc...@gmail.com> 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 <chris.kue...@gmail.com>
> 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 <gnyc...@gmail.com> 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 <
>>> n...@ostatemail.okstate.edu> wrote:
>>>
>>>> On Mon, Oct 6, 2014 at 1:43 AM, Bastian Bloessl <bloe...@ccs-labs.org>
>>>> 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
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> 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?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
