On Nov 13, 2009, at 17:36 , Peter Soetens wrote:

> On Fri, Nov 13, 2009 at 14:00, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>> On Nov 13, 2009, at 05:10 , Peter Soetens wrote:
>>
>>> On Wed, Nov 11, 2009 at 22:58, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>>>> On Nov 11, 2009, at 15:28 , S Roderick wrote:
>>>>
>>>>> On Nov 11, 2009, at 14:02 , Stephen Roderick wrote:
>>>>>
>>>>>> On Nov 10, 2009, at 15:07 , Peter Soetens wrote:
>>>>>>
>>>>>>> On Tue, Nov 10, 2009 at 20:16, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>>>>
>>>>>>>> On Nov 10, 2009, at 09:38 , S Roderick wrote:
>>>>>>>>
>>>>>>>>> On Nov 10, 2009, at 09:28 , Peter Soetens wrote:
>>>>>>>>>
>>>>>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=708

<sni

>>
>> Personally, I'm not worried about releases. I plan to use these on a 1.x branch in my own git repo, but I will open a ticket so that others can follow along if they want to.
>>
>> Thanks for your help with this.
>
> Now that you're using git, why don't you push your 1.x branch to
> github (name it 'for-peter'), then I can pull it in. It's gonna be
> less time for you instead of creating bug reports and it's less time
> for me to review and merge the patches in.

I've done this for bug 733, the integration of TLSF into RTT, plus my patches. I sent you a pull request. First time at this, so please let me know if it is working for you. If it works, then I will also do this for OCL and the other real-time logging related patches.

Also, I'm curious how people have setup their repo's if using github. Particularly when it comes to forking from an existing github repo. I've forked snrkiwi/orocos-rtt from psoetens/orocos-rtt. I then have a copy of that public repo on my machine. Am I better off then to clone this public repo to a private repo on my own machine, and work on the private repo, pushing to public and then to github periodically? Or am I better off trying to also link the public repo back to a completely separate private repo, which is separately tracking your github public repo? Ugh, kinda confusing ... any suggestions, anyone?

Lastly, if at all possible I am hoping to get all these patches into github for you this week. Would love to leave you plenty of patches for review, before I dissappear on a god-awful long flight home to some Kiwi sunshine for a month. :-)

Cheers
Stephen

On Nov 13, 2009, at 17:36 , Peter Soetens wrote:

> On Fri, Nov 13, 2009 at 14:00, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>> On Nov 13, 2009, at 05:10 , Peter Soetens wrote:
>>
>>> On Wed, Nov 11, 2009 at 22:58, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>>>> On Nov 11, 2009, at 15:28 , S Roderick wrote:
>>>>
>>>>> On Nov 11, 2009, at 14:02 , Stephen Roderick wrote:
>>>>>
>>>>>> On Nov 10, 2009, at 15:07 , Peter Soetens wrote:
>>>>>>
>>>>>>> On Tue, Nov 10, 2009 at 20:16, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>>>>
>>>>>>>> On Nov 10, 2009, at 09:38 , S Roderick wrote:
>>>>>>>>
>>>>>>>>> On Nov 10, 2009, at 09:28 , Peter Soetens wrote:
>>>>>>>>>
>>>>>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=708
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --- Comment #16 from Peter Soetens <peter [..] ...>
>>>>>>>>>> 2009-11-10 15:28:07 ---
>>>>>>>>>> I looked briefly through your patches, especially with respect to
>>>>>>>>>> TLSF. You
>>>>>>>>>> assume TLSF is installed as a library, while I had plans to embed it
>>>>>>>>>> into RTT.
>>>>>>>>>> Will your patches break painfully if I require tlsf to come from rtt/
>>>>>>>>>> os/tlsf ?
>>>>>>>>>>
>>>>>>>>>> I also had these in my rtt/os/tlsf/tlsf.h file in order to avoid
>>>>>>>>>> clashes with
>>>>>>>>>> an installed tlsf version:
>>>>>>>>>>
>>>>>>>>>> #define tlsf_malloc oro_rt_malloc
>>>>>>>>>> #define tlsf_free oro_rt_free
>>>>>>>>>> #define tlsf_realloc oro_rt_realloc
>>>>>>>>>> #define tlsf_calloc oro_rt_calloc
>>>>>>>>>>
>>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>> No, don't think it will be a big deal. TLSF embedded into RTT is only
>>>>>>>>> on the v2.x mainline branch, right? I will hack it into my v1.x
>>>>>>>>> install for now, to match.
>>>>>>>
>>>>>>> My old patches were on 1.8.x. I'll port them myself to 2.x.
>>>>>>>
>>>>>>>>
>>>>>>>> Can you ship me a patch for just the TLSF additions to RTT v2? Doesn't
>>>>>>>> have
>>>>>>>> to be fully complete, just enough so that I can backport my patches
>>>>>>>> against
>>>>>>>> it to reduce future pain. Even just the "rtt/os/tlsf/" directory would
>>>>>>>> be
>>>>>>>> enough for starters ...
>>>>>>>
>>>>>>> It's a bit more, but its *untested*. There have to be mistakes in
>>>>>>> there. Based on TLSF 2.4.4.
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> <0001-Imported-raw-tlsf-library-into-rtt-os-tlsf.patch><0002-static-inline-some-functions-to-avoid-double-definit.patch><0003-tlsf-integrate-with-rtt-build-system.patch><0004-tlsf-add-C-allocator-using-rt_malloc-and-rt_free.patch>
>>>>>>
>>>>>> Tested on Hardy and Jaunty. Required patches attached. I rebased to
>>>>>> git/rtt-1.0-svn-patches prior to applying patches, so hopefully all is
>>>>>> clean. I also had to manually apply part of the 0003 patch.
>>>>>
>>>>> Tiny additional patch ...
>>>>>
>>>>> <0001-cmake-Correct-the-directory-for-installing-tlsf-head.patch>
>>>>
>>>> I have now rebased my OCL real-time string patches on top of your RTT/TLSF
>>>> patches (plus my fixes). Only took a couple of hours ... gotta love git
>>>> sometimes ...
>>>>
>>>> How do you want to handle this mix of RTT and OCL patches? Open a new RTT
>>>> bug to track the RTT/TLSF patches?
>>>
>>> I'll soon push a rtt-2.0 branch to github containing these patches for
>>> 2.0. If you want to track them for 1.x, you can attach them to a bug
>>> report. We could set them on 1.x trunk too (why not...) but I can't
>>> promise for a 1.12 release anytime soon, or someone else volunteers to
>>> become the maintainer of the 1.x branches.
>>
>> You start talking about new RTT maintainers, and everyone will start running for the hills!!! :-)
>
> To answer that with a quote of Linus Torvalds this week:
> "The fact is, maintainership does _not_ mean ownership. It means that
> you should be _responsible_ for the code, and you get credit for it,
> but if problems happen you do NOT "own" it. Not at all.
>
> If you don't understand that, you shouldn't be a maintainer."
>
> I couldn't agree more.

Fair enough. Then it sounds like you could use some help ...

>> Personally, I'm not worried about releases. I plan to use these on a 1.x branch in my own git repo, but I will open a ticket so that others can follow along if they want to.
>>
>> Thanks for your help with this.
>
> Now that you're using git, why don't you push your 1.x branch to
> github (name it 'for-peter'), then I can pull it in. It's gonna be
> less time for you instead of creating bug reports and it's less time
> for me to review and merge the patches in.
>
> Peter