On 10/03/2014 12:44 AM, 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.
Sorry for being a buzzkill here,
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.
M
> 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 <marcus.mueller@ettus.com
> <mailto:marcus.mueller@ettus.com>> 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 <martin.braun@ettus.com> <mailto:martin.braun@ettus.com>
>> 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 list
>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto: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
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment