Re: [OctDev] Functions in the core

[Thomas Weber]

On Sun, Apr 12, 2009 at 06:15:02PM -0500, Daniel J Sebald wrote:
> Jaroslav Hajek wrote:
>> On Fri, Apr 10, 2009 at 12:45 PM, Thorsten Meyer <address@hidden> wrote:
>>
>>> Jaroslav Hajek wrote:
>>>
>>>> Maybe we differ slightly in the view of the development archive. IMO
>>>> these are just patches that can easily be reverted. I didn't even yet
>>>> add the functions to the build process, so that they won't be
>>>> installed if someone uses a snapshot - they're just there for
>>>> development testing. So I don't really regard my act as true addition.
>>>> The discussion you call for has just started :)
>>>>
>>>> I don't basically object to a policy that the main archive should be
>>>> regarded as a more sacred place. But as I have explained earlier, IMO
>>>> this significantly clashes with the policy of having a linear archive,
>>>> which makes parallel development for a longer time quite difficult.
>>>> So, if that's going to happen, I think we should allow merges. I'll
>>>> then happily use my experimental repo for most of my development.
>>>> For instance, I've added a couple of new functions (and extended some)
>>>> without discussing with anyone, mostly for use in other functions. I
>>>> hope this is OK, at least nobody complained. Anyone is certainly free
>>>> to raise objections to any of my patches.
>>>>
>>>
>>> I think we should really come to a common understanding about how the
>>> development archive is meant to be used and how "sacred" it is.
>>>
>>> About sacredness: the faster the development of octave advances and the more
>>> contributors we have, I think, the more difficult it will get the avoid that
>>> experimental, uncomplete or inconsistent changes accumulate in the 
>>> development
>>> archive.
>>
>>
>> I see no reason why they should accumulate, unless the corresponding
>> developer is reluctant to clean up after himself. They will certainly
>> happen (and they do happen).
>
> The Hg model of development is fine.  But I would say, watching Octave
> development over several years, that the switch to Hg has brought more
> "bugginess".  I've been watching for months now to jump in and grab a
> version that seems fairly stable, but patches come at a quick rate and
> people are reporting bugs on those patches just days afterward.

The switch to Mercurial has brought a far easier development and I'm
saying this from the point of view of a distribution packager. 

Development has sped up and so more bugs happen. That's life and I don't
think there's too much wrong with it. If anything, at least experienced
users should try to send error-triggering code as unit test, so that it
can be easily included in the test suite. But that's about all I would
propose as changes in the current development.


> The issue is as Carlo stated in reponse to a bug that appeared shortly after 
> 3.0.5 release:
>
> -+-+-+-+-+-+-
> 3.0.5 ?
> Carlo de Falco kingcrimson at tiscali.it
> Tue Apr 7 03:35:50 CDT 2009
>
> Hi,
>
> A bug in loading ascii files with 3.0.4 was recently reported
>
> http://www.nabble.com/Possible-bug-in-%22load%22-function-in-octave-3.0.4-p22892300.html
>
> and very quickly fixed (thanks Benjamin)
>
> http://www.nabble.com/Re%3A-Possible-bug-in-%22load%22-function-in-octave-3.0.4-p22895800.html
>
> don't you think it would make sense to quickly produce a new bug-fix release?
> I believe that leaving such an annoying glitch in the release
> advertised as stable could generate a lot of complaints and bad press.

I couldn't care less about bad press, but then, I'm with Debian and as
we all know, Debian is dying for at least 5 years (or how old is Ubuntu
now?). But what happened above? A bug was fixed (behaviour that differs
from Matlab is generally considered a bug) and that fix introduced
another bug. I don't see how to avoid such a situation. Shouldn't we fix
any bugs in the stable series?

I already said it once: if you only fix regressions in the stable
branch, users will switch to the development branch. It happened pretty
early with the 2.0, 2.1 - 2.9 branches and it will happen again.


> If there is something I can do to help making this happen just let me
> know, I would be glad to contribute.

Add a test file for the above 'load' bug and a unit test in the load
function. That's it. Bugs will happen and they will happen in the stable
series.

> In the past, John kept bugs low such that a release could be made at
> almost any time and in fact John created versions quite often.

http://velveeta.che.wisc.edu/octave/lists/octave-maintainers/2005/246
2.1.68 was released two days before.

Bugs happen. 


> But if we are switching to a mode where code moves in fast and bugs
> are left for others to find, then that release schedule/policy that
> John has followed will result in what Carlos suggests.  Stable code
> with less features is better than the opposite.

Sorry, you are making a mountain out of a molehill. 

> John reviews, but you'll also notice that he does the difficult job of
> finding an fixing bugs in those patches.  Look how many times he's
> said "I applied your patch, but I changed..."

So he can reject them. I consider most of his changes to be for speed or
coding guidelines, not for actual bugs, though.

>> When I eventually realized that there was generally very little
>> opposition to my patches, and that I was able to respond to
>> suggestions quickly, I eventually started pushing most patches
>> straight away except for fundamental changes.
>> It seems to me quite easier to say "get the latest tip to try the
>> stack arrays optimizations" instead of "get revision XXX and apply
>> patches YYY.1, YYY.2 and YYY.3 from my previous mails to try the stack
>> arrays optimizations". At least the first option is much easier for
>> people to actually give it a try.
>
> Well, things like SourceForge make that easier.  Rather than a mailing
> list there is a patch-list where people can go to try the patch.  It's
> usually someone labelled a "developer" which means "overseer", i.e.,
> they try the patch and if there are any problems report back to the
> patch # that something doesn't work.

I understand you volunteer to be such an overseer? Because, people can
already build and check the stable series:

For a start
        hg clone http://hg.tw-math.de/release-3-0-x/
and 
        hg pull -u
for updates. 

The patch that introduced the bug sat there for two weeks, which should
have given plenty of time for testing.

        Thomas