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? >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
