Charles R Harris
Tue Feb 26 15:54:46 CST 2013
On Tue, Feb 26, 2013 at 2:46 PM, Nathaniel Smith <email@example.com> wrote:
> On Tue, Feb 26, 2013 at 9:21 PM, Charles R Harris
> <firstname.lastname@example.org> wrote:
> > On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers <email@example.com>
> > wrote:
> >> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
> >> <firstname.lastname@example.org> 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...
> >> 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
> 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? (I'll try
> not to continue implementing this plan unless we agree on it,
You seem to have a pretty good eye on things.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion