octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stable branch release policy [was Re: Possible bug in intersect]


From: Jaroslav Hajek
Subject: Re: stable branch release policy [was Re: Possible bug in intersect]
Date: Sun, 12 Apr 2009 14:19:46 +0200

On Sun, Apr 12, 2009 at 10:06 AM, Carlo de Falco
<address@hidden> wrote:
>
> On 11 Apr 2009, at 22:54, Carlo de Falco wrote:
>
>>
>> On 11 Apr 2009, at 19:03, address@hidden wrote:
>>
>>> Message: 3
>>> Date: Sat, 11 Apr 2009 17:38:51 +0200
>>> From: Thomas Weber <address@hidden>
>>> Subject: Re: Possible bug in intersect
>>> To: Jaroslav Hajek <address@hidden>
>>> Cc: Massimiliano Culpo <address@hidden>, address@hidden
>>> Message-ID: <address@hidden>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> On Sat, Apr 11, 2009 at 02:11:25PM +0200, Jaroslav Hajek wrote:
>>>>
>>>> On Sat, Apr 11, 2009 at 12:26 PM, Massimiliano Culpo
>>>> <address@hidden> wrote:
>>>>>
>>>>> Please find attached a possible bug occurring in octave-3.0.4.
>>>>> The same behavior is very likely to be found also in octave-3.0.5.
>>>>>
>>>>> Massimiliano Culpo
>>>>>
>>>>
>>>> I fixed this in the development sources.
>>>
>>> Test for this bug attached.
>>>
>>>        Thomas
>>> -------------- next part --------------
>>> # HG changeset patch
>>> # User Thomas Weber <address@hidden>
>>> # Date 1239464264 -7200
>>> # Node ID 68036841138c9ef0365ff0f188f3edfee8eb8460
>>> # Parent  22ae6b3411a769d62f66f196473336440194404a
>>> Add test for bugfix b2459d21a207
>>>
>>> diff --git a/scripts/set/intersect.m b/scripts/set/intersect.m
>>> --- a/scripts/set/intersect.m
>>> +++ b/scripts/set/intersect.m
>>> @@ -104,3 +104,8 @@
>>> %! assert(ib,[3;1]);
>>> %! assert(a(ia,:),c);
>>> %! assert(b(ib,:),c);
>>> +%!test
>>> +%! a = [1 1 1 2 2 2];
>>> +%! b = [1 2 3; 4 5 6];
>>> +%! c = intersect(a,b);
>>> +%! assert(c, [1,2]);
>>>
>>> ------------------------------
>>
>> This behaviour is not compatible:
>>
>> ---------
>> >> a = [1 1 1 2 2 2]
>>
>> a =
>>
>>    1     1     1     2     2     2
>>
>> >> b = [1 2 3; 3 2 1]
>>
>> b =
>>
>>    1     2     3
>>    3     2     1
>>
>> >> intersect(a,b)
>> ??? Error using ==> intersect at 51
>> A and B must be vectors, or 'rows' must be specified.
>>
>> >> intersect(a,b,'rows')
>> ??? Error using ==> intersect at 198
>> A and B must have the same number of columns.
>>
>> >> version
>>
>> ans =
>>
>> 7.5.0.338 (R2007b)
>>
>> >>
>> ---------
>>
>> I would suggest to change the test to
>>
>> ---------
>> c = intersect(a,b(:));
>> assert(c, [1,2]);
>> ---------
>>
>> so that it won't fail if intersect gets changed to be strictly compatible.
>> c.
>
>
> Hi,
>
> It seems this bug was introduced inbetween releases 3.0.3 and 3.0.4 by the
> following changeset:
>
> hg log -r 7920
> changeset:   7920:e56bb65186f6
> user:        Jaroslav Hajek <address@hidden>
> date:        Wed Jun 25 22:11:07 2008 +0200
> summary:     improve set functions for Matlab compatibility
>
> so the question I have is, is there a "bug-fixes only, no new features"
> policy for the "stable" branch?

Sort of. It depends on your view of bug - some users consider
incompatibility with Matlab as a bug. Maybe there was also some bug
fixed by that changeset. I think there were more such "bugs" addressed
between 3.0.3 and 3.0.4.
I think the correct policy would be *regressions only*, as has been
suggested by John, but I don't think that's what most users expect.
That would likely require more frequent stable branches.

> Now, this particular bug is probably to be considered minor as compared to
> the one in "load -ascii" so I'm not sure whether it is worth a 3.0.6
> release,
> but, as it is found in an m-file, maybe a warning about the bug and a link
> to the 3.0.3 version of the set scripts on the web page would suffice?
>
> As an other alternative to new releases in the stable branch, to fix bugs in
> m-files and DLD functions maybe a "bugfix" package in Octave-Forge could be
> used?
>

No problem. Both suggestions sound OK to me.

> Sorry if my suggestions sound stupid, I was just trying to think of a way to
> keep the number of bugs in the stable branch a monotone non-increasing
> function of the release number while requiring as little effort on
> developers like Jaroslav whos precious time is better spent on improving the
> development version.

"non-increasing" probably corresponds to the "regressions only"
strategy, which would be OK with me. But I don't think that works
together with one major release per 16 months (since 3.0.0).
My suggestion was to do a major release in November, after 3.0.3 when
I saw the gap between stable and development sources becoming too big,
but most others reckoned there was not enough new features.
I don't really care that much about the stable releases, because I
work almost exclusively with the development version. To be precise,
I'm fine spending a bit of time on them (like doing the tarballs,
maintaining the archive etc) but I'm not probably the proper one to
decide what should be done here.
What I'd like to follow in the future is the regressions-only
politics, as suggested by John.


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]