On Tue, Feb 26, 2013 at 10:54 PM, Charles R Harris < [email protected]> wrote:
> > > On Tue, Feb 26, 2013 at 2:46 PM, Nathaniel Smith <[email protected]> wrote: > >> On Tue, Feb 26, 2013 at 9:21 PM, Charles R Harris >> <[email protected]> wrote: >> > >> > >> > On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers <[email protected]> >> > wrote: >> >> >> >> >> >> >> >> >> >> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris >> >> <[email protected]> wrote: >> >>> >> >>> When should we put out 1.7.1? Discuss ;) >> >> >> >> >> >> When we have X times more fixes in maintenance/1.7.x than the one >> commit >> >> with a one-liner fix that we have now. Where X is >= 5 at least, unless >> >> there's a very high prio fix that needs releasing asap? >> >> There is, actually; we (probably I) broke >> np.diagonal()/ndarray.diagonal() so any array that has diagonal() >> called on it gets pinned in memory forever. That's why the >> scikits-learn folk are grumpy. >> >> >> Having at least 2 months between bugfix releases unless something very >> >> urgent comes up would also make sense to me. >> >> I'm not sure why -- bug-fixes don't age like wine or anything. >> Obviously there's a trade-off around how much effort we want to spend >> on managing releases versus other things, but I don't see why there'd >> be anything *wrong* with putting out a tiny point-release whenever we >> find a real bug in a stable series. No-one has to upgrade... >> > Nothing wrong per se, just a waste of developer and packager resources if the frequency is too high. Of course if there's 10 bug fixes ready sooner after the previous release, do a bugfix release sooner. But then we should really look in the mirror and ask why there's so many fixes so soon.... >> >> I think we do need to be diligent in backporting fixes quickly after >> >> they're merged into master, and not leaving that till right before the >> >> release candidate is scheduled. >> > >> > Ralph, the backports are PR's marked with the backport tag and there are >> > more than one. It is up to Ondrej to decide whether to include them or >> not. >> >> Oh argh, we should probably document some of this stuff, I just merged >> a bunch of them myself (which all looked fine of course). Mea culpa. >> >> For the moment: Ondrej, heads up that I did this! >> > > That's OK, I think you did a fine job. > > >> >> For the future: I definitely see the benefit of having one person >> keeping track of what goes in and what doesn't as we get into the late >> stage of the release cycle, but in between, maybe it makes sense for >> us all to work together on keeping the basic backports branch up to >> date and taking some of the load off the release manager. > > +1 > (I'll try >> not to continue implementing this plan unless we agree on it, >> though...) >> >> > > You seem to have a pretty good eye on things. > +1 Ralf
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
