[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OctDev] Functions in the core
From: |
Daniel J Sebald |
Subject: |
Re: [OctDev] Functions in the core |
Date: |
Sun, 12 Apr 2009 18:15:02 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
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
- Functions in the core (was: Re: [OctDev] New polynomial functions (Resubmission)), Søren Hauberg, 2009/04/06
- Re: [OctDev] Functions in the core, Daniel J Sebald, 2009/04/06
- Re: [OctDev] Functions in the core, Jaroslav Hajek, 2009/04/07
- Re: [OctDev] Functions in the core, Daniel J Sebald, 2009/04/07
- Re: [OctDev] Functions in the core, Thorsten Meyer, 2009/04/10
- Re: [OctDev] Functions in the core, Jaroslav Hajek, 2009/04/10
- Re: [OctDev] Functions in the core,
Daniel J Sebald <=
- Re: [OctDev] Functions in the core, Thomas Weber, 2009/04/13
- Re: [OctDev] Functions in the core, Jaroslav Hajek, 2009/04/13
- Re: [OctDev] Functions in the core, Daniel J Sebald, 2009/04/13
- Re: [OctDev] Functions in the core, John W. Eaton, 2009/04/15
- Re: [OctDev] Functions in the core, John W. Eaton, 2009/04/15