[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for lo

From: George Nychis
Subject: Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)
Date: Thu, 2 Oct 2014 15:44:19 -0700

Marcus,  I like the idea of an uber-repo with external submodules.  That would mean these submodules could link to a repo we could provide the user, a repo they already have on github, or a repo they have on some other external server.  But in the end, our uber repo would point to all of them and then they could update the commit that external submodule points to over time.  Thanks for that suggestion.

Rick, thanks for this suggestion also!  I will make sure that we are able to include some sort of snapshot.  When you say snapshot here, does that act as some sort of release or history?  It must be different than a tag, since you say tags are part of a snapshot.  Can you give me an example snapshot provided by some other service?

On Thu, Oct 2, 2014 at 7:51 AM, Marcus Müller <address@hidden> wrote:
Hi everyone,

that seems to be a nice solution you're proposing, George. What about having a uber-repo that uses external submodules? This way, you could have your single CGRAN repo, with all the packages as submodules, some documentation in a single wiki, all per gitlab, and just keep the projects as independent repos, hosted on a cgran machine or on github/osmocom/wherever. We get the functionality to backup "all the GNU Radio ecosystem" at once by running some git submodule update command, and pybombs could just clone that repo, and init submodules as the user installs them.


On 30.09.2014 01:00, George Nychis wrote:
I agree with Martin that once we go to git, every project has its own
independent repo.  That shouldn't take much time at all to do, I can just
run some svn2git magic to spit out separate repositories.  The question
will be where those repositories live.  I can host the repositories again.
I could replace the tired Trac interface with Gitlab and then host the
repositories locally and through there.  If that's the case, Github
repositories could be forked in Gitlab and/or point to the Github repos?
(e.g., for people who only want their code on Github).  I think the
downside of Gitlab is that it doesn't seem to be very customizable to, for
example, have a coherent single Wiki of some sort like Trac dd.  It will be
a bunch of separate Wikis buried in to each separate repository's page.

So I think we are agreeing so far on git with multiple repositories for
each project.  What we need to figure out is what the frontend is.

On Mon, Sep 29, 2014 at 3:47 PM, Martin Braun <address@hidden>

On 29.09.2014 14:55, Marcus D. Leech wrote:

I have no religious convictions about git vs svn.

I'd have to change a couple of scripts [...]

When CGRAN was inaugurated, github wasn't as popular as it was (and GNU
Radio was still on SVN itself). We would not have gone for a central SVN
repo if github had been on our radar back then.

I guess most people either share Marcus' sentiment, or are biased towards
git. So, ditching SVN is pretty much a no-brainer.

However, one major difference between SVN and git is that the latter
doesn't have the concept of every dir being a repo in and of itself.
This means if we simply pushed everything to a giant github repo, that
would not be terribly useful (definitely not a replacement for CGRAN),
although I can see that being a temp solution so that at the very least,
nothing is lost (a big advantage of using github is that they're less
likely to lose data).

Really, every CGRAN project should be pulled into it's own little repo,
e.g. on github. Migrating from SVN to git is really easy (even with
preserving history and all). I guess we could put up instructions on how to
do that if there's popular demand.

However, there's also the wiki pages on CGRAN. We do need a strategy for
those (and a way to access them).

Keep the ideas and comments coming, people!



Discuss-gnuradio mailing list


Discuss-gnuradio mailing list

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]