On Mon, Oct 6, 2014 at 1:43 AM, Bastian Bloessl <[email protected]> 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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
