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

[Joe Harrington]

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.

> >   If they pull, who does it, and what's the best way to signal
> > them that it's time to pull, given that they're not on our lists and
> > that for many distros, the person responsible for the package might
> > not use or even personally care about our software.
> >   
> 
> In my experience, what matters the most is maintainer time (I sound like
> a broken record, don't I ? :) ). If they have some time, they will
> update - but there is the problem that the window to update a version
> does not always fit with maintainer 'free' time. Then, there is the
> incentive of users asking for it.

Your time or theirs?  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.

> One thing to keep in mind, which may not be obvious to everyone: our
> goal, as numpy/scipy developers, and the distributions goals are not the
> same, if not antithetic. We care about distributing the most recent
> version, and they care about stability and the least work possible. Not
> updating is almost always easier than updating for them. For example,
> some RH developers are really pissed about python 3k breaking a lot of
> stuff, and would even want to see python 3k failing so that they don't
> have to deal with the numerous maintenance problems (see
> http://lwn.net/Articles/310450/). Another example is that debian
> developers would like to split numpy in many small pieces, because numpy
> is too big; from our POV, that does not make any sense.

Well, it's not completely antithetic: we all want to take as little
time as possible!:-) We can't force them into action, but one thing is
certain:  They won't take more action if users don't ask them to.  A
little human contact will go a long way.

> My own opinion is that the only solution is to have our own packages,
> published when we can; distributions then do what they want/can on their
> own schedule.

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.

> > This is actually good news.  Maybe we'd be more up-to-date in the
> > distros if we had some volunteers act as liasons between the Packaging
> > Team and the distros.  All they'd have to do would be to follow the
> > instructions on the Distros page to ping the distros whenever we cut a
> > new release.  There are plenty of newish folks who have asked how they
> > could help, but who can't actually contribute code or docs yet.  This
> > would be a good task for them.  It would only take one or two people.
> >   
> 
> I am not sure packaging counts as a good task for newcomers. Packaging
> is difficult to do well, there are a lof of small details to keep right,
> and there is a lot of politics involved, which does not sound as the
> kind of things newcomers would like to do.

I'm not advocating bringing lots of newbies into the binary packaging
effort.  I'm suggesting that we sign up a few people, who may be
newbies to Python but may not be newbies to programming and even
packaging, to follow the instructions on a web page about sending an
email once a release.  This is just not a big deal, but it could have
a significant return, because, sorry if I sound like a broken record,
but: a little human contact will go a long way.

--jh--