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
