[SciPy-dev] updating the numpy/scipy versions in Linux distros

[David Cournapeau]

Joe Harrington wrote:
> Hi David, greetings from not-so-faraway Tokyo...
>
> David Cournapeau wrote:
>   
>>> For the second part of the problem, of course there's no reason for us
>>> to document what Ubuntu or any other distro does to cut one of their
>>> releases.  What's needed is to document how our stuff gets into their
>>> release.
>>>       
>> I think there is little to document, because there is no formal process
>> between "us" and "them". There is a lot of process within a
>> distribution, what's go where and when for which version, but that's
>> documented on each distribution.
>>     
>
> So document the little there is to document.  I don't expect that it
> takes more than an email or a click on a web page to get most
> distributors to put "pick up new numpy before next build" on their
> to-do list.  But we could benefit, because as you point out these are
> busy people and they might not bother looking on their own every
> release.  What I'm looking for on each distro may be no more than:
>
> The Fnord release process is described at:
> http://releases.fnord.com/timetable.html
>
> The current numpy in Fnord is: 1.2.3
> The current scipy in Fnord is: 4.5.6
>
> The Fnord Numpy build is based at http://building.fnord.com/numpy/
>
> Fnord Smith <fnsmith at fnord.com> handles both numpy and scipy packages
> for Fnord.
>
> The best way to get a new numpy release into Fnord is to email
> fnordsmith at fnord.com as soon as it's released.
>   

I don't think we can do that: it changes too often, and it is almost
guaranteed it won't be updated accordingly. No info is better than wrong
info IMHO. And the info is easily available on the given distributions.

Unless you have something which is 100 % automated and full proof, I
don't think it is a good idea.

>
> Your time or theirs?

theirs. Specially for numpy, it takes a long time to integrate well
(because many packages depend on it; one example: numpy causes trouble
because of pygtk for next Ubuntu - that's not something we care about).

>   I'm not asking for more of your time.  But, if
> we organize ourselves just a little, and ping the distros when we have
> a new release, maybe someone on their end (perhaps even someone in our
> community) will take the time to ingest a new release into their
> system before they start hitting deadlines.  Again, a little human
> contact will go a long way.
>   

FWIW, I recently joined debian python packagers ML, and I have svn
access to fix some issues. That goes toward your human contact, I think :)

>
> Well, it's not completely antithetic: we all want to take as little
> time as possible!:-) 

What is antithetic is that we care about being up to date, and they care
about stability. Since we don't have a fully backward release process
(which is not possible in python anyway), that's a big problem for
distributions.  Once say scipy 0.7 is released, we don't care at all
about 0.6 anymore. But they do. They care that numpy 1.3 may break 20
packages which depend on it. Think about stable releases (several
years), where they anyway have to care about old releases (which we
don't); ubuntu hardy will have to support numpy 1.1.1 for several years
to come anyway. Every new version means more work, because they still
have to support the old one anyway.

> Didn't we switch to frequent, time-based releases in part to make it
> so that anybody picking up a package got a relatively recent version?
> Our interests don't have to conflict with theirs if we think
> creatively and even talk to them occasionally.
>   

It is more complicated than that. A good example is bzr: that's a
software which is crucial to Canonical, and is updated every month. It
is heavily funded by Canonical. Yet, how do bzr developers distribute
bzr ? By producing the .deb themselves, and distributing it to the PPA.

That's why I think we should focus on things like PPA: we can do the
same process for every distribution that matters, in a centralized way,
which we can document. It can be mostly automated. By being independent
of the distributions, we avoid the pain, while having most of the benefits.

Trying to make things faster on the distribution side of things is
hopeless in my experience - if you look at many big projects out there
which care about Linux, they all distribute their own packages (mono,
bzr, etc...).

cheers,

David