discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] What happened to pybombs git repository?


From: Alexandru Csete
Subject: Re: [Discuss-gnuradio] What happened to pybombs git repository?
Date: Sun, 25 Aug 2013 00:13:34 +0200

On Sat, Aug 24, 2013 at 9:24 PM, Tom Rondeau <address@hidden> wrote:
> On Sat, Aug 24, 2013 at 5:30 AM, Alexandru Csete <address@hidden> wrote:
>> Greetings,
>>
>> Today I was trying to merge the last changes from pybombs/pybombs into
>> my own copy in csete/pybombs. The merge kept failing as if there was a
>> conflict in every single file.
>>
>> Looking at the pybombs repository there is indeed something strange.
>> All history is missing and there is only one commit which in turn adds
>> everything?
>>
>> I leave my own copy untouched for now in case you need a reference for
>> restoring the repository. My own copy is up to date up until the last
>> commit few days ago by Tom.
>> https://github.com/csete/pybombs
>>
>> Alex
>
>
> Alex,
>
> This was done on purpose. When we changed the license, we decided to
> remove the pre-licensed code. I found what should have been the
> cleanest way to handle this, but I knew it was going to cause a
> force-update on anyone's local branch when you pulled it down[1]. Any
> new clones will just get this one checkout.
>
> There's no need to preserve the code in this case. The only real
> reason would be if people wanted to go in and add their copyright for
> code they've changed. We're handling PyBOMBS differently than GNU
> Radio where we're not assigning copyright to FSF. It's GPLv3 and
> copyright is whoever made the copyrightable changes or additions to
> the code. I figured most of the patches submitted have largely been
> recipe-related (except some code work by Ben). If people feel the need
> to put their copyright notice on the recipes, then that's fine. I
> didn't think it was very important since recipes are very specific in
> format to PyBOMBS, so the copyright doesn't protect much (the code, on
> the other hand, is a bit different).
>
> [1] It's quite possible there is an even better way than how I did it
> via git. But I looked at various ways and discussions on this topic
> and picked what seemed to be the 'preferred' way. Oh... and if there
> was a better way, I don't really care at this point :)

Ok, no problem. I'll just clone again.

Alex



reply via email to

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