[Numpy-discussion] Wanted: new release manager for 1.5 and above
Sat Jan 16 03:19:13 CST 2010
On Sat, Jan 16, 2010 at 4:57 PM, Ralf Gommers
> On Fri, Jan 15, 2010 at 11:56 PM, David Cournapeau <email@example.com>
>> > How many combinations do you test manually? All supported Python
>> > versions on
>> > all platforms? Several Linux flavors?
>> I basically assume that linux works once the branch is stabilized, if
>> only because that's what most developers use. It is important to test
>> on the oldest supported python (2.4) and both 32 and 64 bits, though
>> (especially python 2.4 on 64 bits).
>> I never test the installers - this is too much work manually. Ideally,
>> this should be done on a build/test farm.
>> > For someone new to packaging, how much time would you estimate it takes
>> > to
>> > do a single release? Is most of this time spent testing, or fixing the
>> > problems you find during testing?
>> Most of the time is spent on fixing build issues which crop up during
>> the beta phase. I found difficult to enforce a strict policy on not
>> changing anything unless critical once in the beta phase. I think we
>> should improve things in that aspect, and go away from the "but this
>> is a small fix" mentality - maybe using something like for the linux
>> kernel, with merge windows, etc... I secretly hope that if we can
>> regularly change release managers, it will give a sense of why this is
>> good policy :)
>> I feel that we have improved things quite a bit since I have started
>> doing releases: the binary installers are more stable, and build are
>> mostly automated now. The next step would be automated testing of the
>> binary installers (in particular testing new numpy against scipy,
>> etc...), but this is quite a bit of work.
>> Having a stricter time-based policy would be good as well.
> Thanks for the explanations. I volunteer to help as well.
> From working on
> the docs and scikits.image I am familiar with most of NumPy/SciPy, but not
> with the C internals.
That's not a problem - I was not either when I started doing it. And
there are still a lot of areas I am not familiar with. There is no
need to know everything about numpy to do a good job.
One thing you could start doing is trying to make the mac os x dmg
from the paver script, and familiarize yourself with virtualenv if you
don't know it (I use virtualenv to install numpy in a temporary
directory before building the doc - this guarantees that the doc
matches the exact same version of numpy as the one you are packaging).
I spent some time cleaning the paver script before the 1.4.0 release,
so it should hopefully be readable.
More information about the NumPy-Discussion