[GEM-dev] financing Gem development

Max abonnements at revolwear.com
Mon Nov 20 12:27:17 CET 2017


What about something for linux? Generally support a new release?


On 2017년 11월 17일 18:07, cyrille henry wrote:
> it appear that pledgie is dedicatad to find money for your work, better 
> than financing other work.
> i.e, if I crete a project, I'll receive the donation.
> 
> So, I went with bounty source.
> I create 4 bounty:
> 
> https://www.bountysource.com/issues/3383537-w32-build-msvc
> https://www.bountysource.com/issues/4185679-native-video-capturing-on-osx-64bit 
> 
> https://www.bountysource.com/issues/4185729-native-film-reading-on-osx-64bit 
> 
> https://www.bountysource.com/issues/6492784-native-image-reading-writing-on-osx-64bit 
> 
> 
> They correspond to the 4 most important bug I found on the gitub 
> bugtracker.
> 
> It's time to find money!
> 
> 
> Le 15/11/2017 à 18:05, cyrille henry a écrit :
>> hello,
>> i'm sorry it took so long, I have lot's of work.
>>
>> I found 2 platform :
>>
>> https://pledgie.com/
>> and :
>> https://www.bountysource.com/
>>
>> pledgie get 3% of the donation, bountysource get 10%.
>>
>> unless anyone have a better idea, i'll start to go with pledgie
>> cheers
>> c
>>
>>
>>
>> Le 30/10/2017 à 17:38, cyrille henry a écrit :
>>> Hello,
>>>
>>> I've check Iohannes github: There is not a lot's of release critical 
>>> issue.
>>>
>>> Image, film and video under osX and having a way to compile for 
>>> window and the main issues.
>>>
>>> There is also lot's of stuff regarding FTGL, but they look to be 
>>> obsolete. At least, we will know if they are obsolete after being 
>>> able to compile Gem on the concerned platform.
>>>
>>> Since Iohannes is currently too buzzy to help, I think we should 
>>> organize development in 2 parts :
>>>
>>> 1st : doing the minimum to have Gem usable on all platform.
>>> We could then release a v0.94 and use it to test on lot's of computer 
>>> and reporting all bugs.
>>> Then, a 2nd development round could create a 0.94.1 bugfix release 
>>> with a longer lifetime.
>>>
>>> if there is no objection, I will have a look at the platform we could 
>>> use to centralize financing and stuff.
>>> cheers
>>> c
>>>
>>>
>>>
>>> Le 12/10/2017 à 10:34, cyrille henry a écrit :
>>>> hello Max
>>>>
>>>> Le 12/10/2017 à 10:04, Max a écrit :
>>>>> Bonjour Cyrille,
>>>>>
>>>>> This sounds good, there was the idea of some bounty system years 
>>>>> ago too.
>>>>> I think it's crucial for this process to
>>>>>
>>>>> 1. break up the job in small manageable parts
>>>> yes, that's the idea of using the github bug tracker. Spiting jobs 
>>>> in bugs.
>>>> (and use flags to create priorities)
>>>>
>>>>
>>>>> 2. well define their scope and define what "job completed" entails
>>>> I think it imply that the push request is accepted, and the code is 
>>>> merged upstream.
>>>>
>>>>> 3. set up a system that doesn't come with a huge administration 
>>>>> overhead
>>>>
>>>> yes, this is a problem.
>>>> The reduce amount of developers interested in this job will make 
>>>> things simpler.
>>>>
>>>>>
>>>>> It almost seem there should be a platform for this out there...
>>>>
>>>> yes, I don't think administration will be a show stopper.
>>>>
>>>>
>>>>> https://www.bountysource.com/teams/pure-data/issues
>>>>> this one looks like it parses github issues.. kind of shady.
>>>>>
>>>>>
>>>>>
>>>>> On 2017년 10월 12일 09:46, cyrille henry wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Since the "get money, paid a developer" idea arise on the mailing 
>>>>>> list, I spend last weeks trying to think how to organize the last 
>>>>>> bit of development that need to be done.
>>>>>>
>>>>>> I think we need a clear roadmap : a list of all object / platform 
>>>>>> that need to be fixed. My proposition is to use/update the 
>>>>>> bugtracker and to organize everything that need to be done under 
>>>>>> the "release critical" tag. There is a bit of work there. For 
>>>>>> example "native film reading in osX/64 bit" is not mark as release 
>>>>>> critical.
>>>>>> Also, there is 2 critical bug regarding W32 build : do we need to 
>>>>>> be able to compile Gem on mingw AND mscv?
>>>>>>
>>>>>> With this list of "release critical" bugs, it will be easier to 
>>>>>> estimate the work that need to be done. It will allow to estimate 
>>>>>> the development time, and the bounty we could offer for this work.
>>>>>>
>>>>>> With the financial help of New Blankets, other institutions, 
>>>>>> associations or users, I confident that we will be able to finance 
>>>>>> this work (or part of this work).
>>>>>>
>>>>>> does this sound good?
>>>>>>
>>>>>> cheers
>>>>>> Cyrille
>>>>>>
>>>>>> _______________________________________________
>>>>>> GEM-dev mailing list
>>>>>> GEM-dev at lists.iem.at
>>>>>> https://lists.puredata.info/listinfo/gem-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> GEM-dev mailing list
>>>>> GEM-dev at lists.iem.at
>>>>> https://lists.puredata.info/listinfo/gem-dev
>>>>
>>>> _______________________________________________
>>>> GEM-dev mailing list
>>>> GEM-dev at lists.iem.at
>>>> https://lists.puredata.info/listinfo/gem-dev
>>>
>>> _______________________________________________
>>> GEM-dev mailing list
>>> GEM-dev at lists.iem.at
>>> https://lists.puredata.info/listinfo/gem-dev
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/gem-dev
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> https://lists.puredata.info/listinfo/gem-dev




More information about the GEM-dev mailing list