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
