[GEM-dev] financing Gem development

[Jack]

Or for all platforms ?
In vertex processing with have :
- vertex shader
- geometry shader

What about tesselation shader ?

I use Gem a lot so i will be happy to participate financially if that
can help to add functionality to it.
++

Jack




Le 20/11/2017 à 12:27, Max a écrit :
> 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
> 
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> https://lists.puredata.info/listinfo/gem-dev