[GEM-dev] financing Gem development

[Chris Clepper]

It took me a very long time to write all of the Quicktime code for
pix_film/record/video and have it run well.  I think pix_record took a few
months to write working on it nearly full time.  After that it was a lot
more work to have them all run for months at a time without crashing.  I
was being paid to do it - along with the DirectShow code and a bunch of
other things.

A lot of the issues stemmed from how far apart Apple's intended use for the
code and what GEM needs to do were.  I would expect the newer frameworks
that are much more limited than the original ones to be a decent struggle
for performance and stability.

Chris

PS - I have no interest in writing code for anything Apple or any other
desktop OS again.

On Mon, Oct 30, 2017 at 12:38 PM, cyrille henry <ch at chnry.net> wrote:

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