[GEM-dev] financing Gem development

[Ivica Ico Bukvic]

Why not instead focus on Jonathan's work on implementing WebGL inside
Purr-Data canvas (which is already in node webkit) and by doing so obtain
most of the Gem functionality in a way that does not mess with the audio
interrupt?

On Nov 15, 2017 12:05, "cyrille henry" <ch at chnry.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20171115/8e69726a/attachment.html>