Charles R Harris wrote: > > > On Fri, Jan 15, 2010 at 8:56 AM, David Cournapeau <courn...@gmail.com > <mailto:courn...@gmail.com>> wrote: > > On Fri, Jan 15, 2010 at 11:46 PM, Ralf Gommers > <ralf.gomm...@googlemail.com <mailto:ralf.gomm...@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 > <da...@silveregg.co.jp <mailto:da...@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.) -- Dag Sverre _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion