[Numpy-discussion] Wanted: new release manager for 1.5 and above

[Dag Sverre Seljebotn]

David Cournapeau wrote:
> On Sat, Jan 16, 2010 at 4:30 PM, Dag Sverre Seljebotn
> <dagss at student.matnat.uio.no> wrote:
>> Charles R Harris wrote:
>>>
>>> On Fri, Jan 15, 2010 at 8:56 AM, David Cournapeau <cournape at gmail.com
>>> <mailto:cournape at gmail.com>> wrote:
>>>
>>>     On Fri, Jan 15, 2010 at 11:46 PM, Ralf Gommers
>>>     <ralf.gommers at googlemail.com <mailto:ralf.gommers at googlemail.com>>
>>>     wrote:
>>>      > Hi David,
>>>      >
>>>      > Here are some questions to get a clearer idea of exactly what's
>>>     involved in
>>>      > / required for making a release.
>>>      >
>>>      > On Thu, Jan 14, 2010 at 2:34 PM, David Cournapeau
>>>     <david at silveregg.co.jp <mailto:david at silveregg.co.jp>>
>>>      > wrote:
>>>      >>
>>>      >> Charles R Harris wrote:
>>>      >>
>>>      >> >
>>>      >> >
>>>      >> > What is the setup one needs to build the installers? It might
>>>     be well to
>>>      >> > document that, the dependencies, and the process.
>>>      >>
>>>      >> Right. The top script is:
>>>      >> http://projects.scipy.org/numpy/browser/trunk/release.sh
>>>      >>
>>>      >> the bulk of the work is in :
>>>      >> http://projects.scipy.org/numpy/browser/trunk/pavement.py
>>>      >>
>>>      >> which describes what is needed to build installers. On mac os x, the
>>>      >> release script may be used as is to build every installer + the
>>>     release
>>>      >> notes.
>>>      >>
>>>      >
>>>      > Is it necessary to have OS X to build the dmg installer, or could
>>>     you build
>>>      > that from linux with some modifications to the build script?
>>>
>>>     You cannot cross compile python extensions, so you have to build
>>>     installer on each platform. Mac Os X is the most practical because you
>>>     can build windows installers under wine, so you can build both mac and
>>>     windows installers from the same machine.
>>>
>>>     The paver script + the shell script can build everything in one step
>>>     thanks to this.
>>>
>>>      >
>>>      > 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.
>>>
>>>      > Do you have an idea about when to start preparing for the release
>>>     of 1.4.1?
>>>
>>>     The cython thing is the most problematic bug, and should be fixed
>>>     ASAP. I am still not sure whether that would require both a numpy
>>>     1.4.1 and a scipy 0.7.1.1 (built against numpy 1.3.0).
>>>
>>>
>>> Speaking of the cython thing, do you know if the last release of cython
>>> (0.12) fixes that problem?
>>>
>> If you people referred to this "thing" in slightly more detail, I could
>> probably answer that :-)
>>
>> (If you mean the problems with building a binary for more than one
>> version of NumPy at once, then no, I don't believe that is even fixed in
>> trunk yet, though it is trivial to do so its just to remember to do it
>> before 0.12.1.)
> 
> I thought the fix 9d8b2ecef24a (on cython-devel branch) by was
> supposed to fix it ? I try to apply this to cython-stable, but there
> were some issues, and did not want to waste time on it since it may be
> trivial to do for someone familiar with cython internals.

Right, missed that one. Looks like it should fix it, yes.

I'm guessing that cython-devel could pretty much be rolled straight into 
0.12.1 now if you need it (however every release means spending time 
testing etc.., and I'm not volunteering at this point, so I'm not 
raising the point on cython-dev..).

-- 
Dag Sverre