[Cython] funding (Re: sage.math problems?)

[Robert Bradshaw]

On Thu, Mar 22, 2012 at 12:03 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Dag Sverre Seljebotn, 22.03.2012 19:21:
>> On 03/22/2012 10:52 AM, Stefan Behnel wrote:
>>> Dag Sverre Seljebotn, 22.03.2012 17:58:
>>>> On 03/22/2012 09:03 AM, Stefan Behnel wrote:
>>>>> I would prefer copying the original installation over
>>>>> (including the build history), rather than rebuilding it.
>>>>
>>>> I hope it doesn't come to this, but if it does, I think we should really
>>>> look hard at ShiningPanda instead.
>>>
>>> We could set up an OSS test account to see what we'd get for our money,
>>> i.e. how much of our build/test cycle we can put into one hour in their
>>> environment.
>>>
>>>> Honestly, my feeling is that if we can't rally up $240/month in funding
>>>> among Cython users then we might as well give up.
>>>
>>> As long as we have sage.math, I can think of better things to do with 240$
>>> per month. Didn't we want to organise another workshop at some point?
>>
>> I honestly don't think there's a lack of money for things like this once we
>> go around asking; the most expensive part of any workshop is the time of
>> the participants.
>>
>> Workshops in particular may be fundable through William's grant. The main
>> problem is when people are available. Robert will not be available for some
>> time, and neither will I (though I'm much less important these days), but
>> if the rest would like to meet up I'm sure it is fundable one way or the
>> other.
>
> Yep, sounds like a time rather than money issue.
>
>
>>> Regarding funding in general, maybe we should just start putting up one or
>>> two of those sexy funding bars on our web site, like the PyPy devs do for
>>> their funded projects. Assuming that goes well, it would also allow us to
>>> put money on dedicated projects by paying basically ourselves for doing
>>> tasks that we won't normally spend our precious spare time on (e.g. because
>>> they appear too large for a weekend), but that we and our users deem
>>> necessary for some reason.
>>
>> Well, outright funding for projects is of a totally different order of
>> magnitude. The $240 doesn't pay for more than between 1 and 4 hours of
>> "grown-up" developer time (at least in Western Europe and US); for serious
>> feature-funding you're starting to need thousands or tens-of-thousands of
>> dollars rather than hundreds.
>
> PyPy manages to get those amounts. Just look at their home page, the
> projects are all in the tens of thousands of dollars. I don't think that's
> impossible for us.

Cool, that's promising. Do you think we would have the developer
resources to follow through if we did something like this?

>> Smaller constant-amount bounties (like GSoC) for fun stuff one would have
>> motivation to do otherwise is a different matter. My impression is that a)
>> core devs have no more time for Cython than they spend already, b) Cython
>> development is a bit too difficult to enter for random "bounty-hunters".
>
> Regarding b), PyPy is far worse.

Possibly.

> Regarding a), I'm not so sure. At least I would consider it a way to focus
> my work. Currently, I'm rather reluctant to starting anything that looks
> like more than a couple of evenings or a weekend.

Though the crazyiness in my personal life over the last 6+ months is
winding down, I doubt I'd have enough spare time to be, e.g., the
equivalent of 1/4-full time, or that funding would significantly
change the situation. But that's not an argument against not letting
you (and the rest of the project) benefit.

>> Slightly related: I believe the best thing we can do to attract more
>> developers is to seriously clean up the codebase. My new year's resolution
>> is that if I get some days for working on Cython this year (I hope to),
>> I'll spend it only on cleaning up the codebase, not on (even simple) features.
>
> Yay!

+100

>>> Basically, any "real" CEP that we consider doable and that we'd have a
>>> developer for could get a funding account where users could "vote" for it
>>> by donating money.
>>>
>>> (and that's where the legal issues start ...)
>>
>> Well, I seem to remember from a talk that NumFOCUS will have a full-time
>> (or part-time?) position to deal with such administration. And they'll be
>> set up as a non-profit (so tax-exempt for US-based donations). So I think
>> that's a better route than PayPal.
>
> Sounds like it. Is their tax-exempt status restricted to the US? That would
> be unfortunate for many donators.

Tax-exempt status is a criteria set by each individual government, not
by the entity. I'm sure if it helped money flow in they would consider
filing the necessary paperwork.

>> Should we solicit donations on our webpage with a link to NumFOCUS? (I can
>> ask NumFOCUS whether they're cool with that.)
>
> Interesting. If they have the administration set up (BTW, is that paid or
> do they want something for that?), they should be able to handle project
> specific money as well.
>
>
>>> Speaking for myself, I don't consider the time wasted that I invested into
>>> the Jenkins setup so far, and I'm also not sure there'd be all that much to
>>> gain by no longer administrating the server installation itself by
>>> ourselves. The bulk of the work is about configuring jobs and writing
>>> build/test/whatever scripts, which still applies to a cloud installation
>>> (with, I assume, the added disadvantage of no longer being able to ssh
>>> directly into the machine).
>>
>> There is SSH access at least to the environment where the tests are run,
>> according to their web pages.
>
> Ok, that's cool.
>
>
>>>> ShiningPanda also offers features like testing on Windows.
>>>
>>> That *is* a feature, but it also takes up additional (paid) time. We
>>> wouldn't have to run continuous tests on it, though, just trigger tests
>>> manually when we want them.
>>
>> And it's in beta so far. But it's a feature sage.math will never get.
>
> Sure. However, most code we write isn't platform specific, and having a CI
> server run Windows tests doesn't always help in debugging them if you don't
> have a Windows box to reproduce the problem. Their SSH access may help on
> that one (assuming that you get a usable environment there, including
> MinGW/gdb or Microsoft's compiler environment), but I should note that
> setting up the Jenkins jobs for Windows basically means rewriting them
> completely (and remotely). What do you even get when you ssh into their
> Windows box? Not a DOS prompt, I hope?

Even if we couldn't debug remotely, just having a continuous build
setup would be a huge boon for being able to locate the commits that
cause trouble rather than trying to debug a release candidate much
later.

- Robert