Re: [OctDev] Functions in the core

[Daniel J Sebald]

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 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.

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

c.
-+-+-+-+-+-+-

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.

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.


> > Once this happens, it could be quite tedious (and not much fun at all)
> > to clean it up again. So I personally would prefer to have clear and rather
> > strict rules about what is allowed to go into the development archive.
>
>
> Personally, I felt the ability to push directly to savannah hg as
> important boost for my contributions, because I no longer needed to
> wait until someone, usually JWE, reviewed and approved my patches.

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..."


> 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.

Dan