Re: [OctDev] Functions in the core

[Daniel J Sebald]

Jaroslav Hajek wrote:
> On Mon, Apr 13, 2009 at 1:15 AM, Daniel J Sebald <address@hidden> 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,
>
>
> The stable releases should be fairly stable. Except 3.0.4, which was a
> disaster, but an accident.
>
>
> > but patches come at a quick rate and
> > people are reporting bugs on those patches just days afterward.
>
>
> Yes, that's what I like about it. That's one of the strongest points
> of free software.

I agree.  But I think for that to be a substitute for thorough testing isn't 
good.


> > 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.
>
>
> Unfortunately, it seems John now has less time than in the past.
>
>
> > 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.
>
>
> Says who? I use the development branch due to new features.

Probably not anyone on this list, because these are all the people looking for 
new features.  But the rudimentary user who finds bugs in a program s/he tries 
gets a first impression and then dismisses the product.  It's hard to get 
people back from that.  Case in point?  Windows.  A few blue screens and one 
becomes a linux user and doesn't look back.


> When I
> find a bug, I fix it (or someone else does), update code, rebuild and
> the bug is gone.

You have to remember that there are many users out there who aren't like you or 
me.  They don't have the confidence that if a program they decide to use has a 
bug, they can notify a discussion list, get a development version and compile 
it.


> > > > 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..."
>
>
> No question John is a great programmer and maybe the only person who
> understands the whole code of Octave, but I don't think he did
> anything more magical with the patches than we all do.

But John does have a higher level of patience... most days.  It's a matter of hastiness.  If the premise is, as Thomas suggests, "bugs happen" but someone will find them, it seems to me programmers are more inclined to be sloppy, which I'm not saying anyone is.  


> I assure you I don't intentionally leave bugs in my patches.

Few do.  


> > > 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.
>
>
> Feel free to propose using any mechanism to improve testing of Octave.
> Just to clarify what I meant - it does not matter much where the
> patches can be found. The thing is that working with repos is easier
> than working with standalone patches, and that's what mercurial is
> best designed to do.
> Trying a new feature in the development repo is, for me, as easy as
> "hg pull -u; make -j2".

Yes, easy.  But maintaining quality is more of a process issue.  If one looks 
at industry programming and the way it has been moving, the process includes 
report bug, assign programmer, fix bug, someone else confirm bug fixed.  There 
are usually two components to software development: source control and bug 
tracking tool.  The bug tracking tool is the procedural part of the development.

Dan