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 <[email protected]> >> 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 ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
