[Numpy-discussion] 1.7.1

[Ralf Gommers]

On Tue, Feb 26, 2013 at 10:54 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> On Tue, Feb 26, 2013 at 2:46 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Tue, Feb 26, 2013 at 9:21 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> >
>> > On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers <ralf.gommers at gmail.com>
>> > wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
>> >> <charlesr.harris at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130226/26476a7d/attachment.html>