Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[Rick Farina]

On 10/02/2014 06:44 PM, George Nychis wrote:
> 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?
> 
For example a github repo:

https://github.com/csete/gqrx/tree/v2.3.1

This link to a tag shows you the state of the repo when it was tagged,
but the exciting part is along the right hand side where it says
"download zip":

https://github.com/csete/gqrx/archive/v2.3.1.zip

Github also supports tgz (but not tbz2 or txz because apparently github
is from 1995).

To be able to download any commit as a tarball is a very very useful
feature on github.  Again, I don't actually care about git or github,
just that this specific feature is great.  For some reason a lot of SDR
projects just never seem to make releases (sometimes not even tags) and
this saves me having to make manual tarballs (it also helps the source
tarball be the same across all distros since we don't each have to make
our own).

Thanks for the consideration,
Zero

> 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.
>>
>> Greetings,
>> Marcus
>>
>>
>> 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> 
>> <address@hidden>
>> wrote:
>>
>>
>>  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!
>>
>> Cheers,
>>
>> M
>>
>> _______________________________________________
>> Discuss-gnuradio mailing 
>> address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing 
>> address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>