Re: [Monetdb-developers] [Monetdb-checkins] MonetDB5/src/mal mal.mx, 1.110, 1.111 mal_instruction.mx, 1.264, 1.265 mal_resolve.mx, 1.122, 1.123
On Wed, Jan 31, 2007 at 09:27:31PM +0000, Martin Kersten wrote:
Update of /cvsroot/monetdb/MonetDB5/src/mal In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv31774
Modified Files: mal.mx mal_instruction.mx mal_resolve.mx Log Message: mal.mx mal_resolve.mx, website documentation
is the new website built for the development trunk or from the release branch? with the old website, it used to be the latter...
mal_instruction, protect against too many variables.
these were checked-in the development trunk, but the message sounds less like "new features" rather more like "bug fixes" --- aren't they also relevant for the release branch and a possible bugfix release? Stefan
Index: mal_instruction.mx =================================================================== RCS file: /cvsroot/monetdb/MonetDB5/src/mal/mal_instruction.mx,v retrieving revision 1.264 retrieving revision 1.265 diff -u -d -r1.264 -r1.265 --- mal_instruction.mx 24 Jan 2007 23:49:10 -0000 1.264 +++ mal_instruction.mx 31 Jan 2007 21:27:29 -0000 1.265 @@ -1247,6 +1247,10 @@ cheap to perform a linear search to a variable or constant.
@= makeVarSpace + if( mb->vtop >= (1<<15)-2 ){ + mb->vtop = (1<<15)-2 ; + GDKerror("newVariable: too many variables\n"); + } else if( mb->vtop >= mb->vsize){ VarPtr *new; int s= mb->vtop + MAXVARS;
Index: mal_resolve.mx =================================================================== RCS file: /cvsroot/monetdb/MonetDB5/src/mal/mal_resolve.mx,v retrieving revision 1.122 retrieving revision 1.123 diff -u -d -r1.122 -r1.123 --- mal_resolve.mx 7 Jan 2007 05:25:01 -0000 1.122 +++ mal_resolve.mx 31 Jan 2007 21:27:29 -0000 1.123 @@ -16,11 +16,6 @@
@a M. Kersten @v 1.0 -@- -@menu -* Type Resolution:: -* User Defined Types:: -@end menu @+ Type Resolution Given the interpretative nature of many of the MAL instructions, when and where type resolution takes place is a critical design issue.
Index: mal.mx =================================================================== RCS file: /cvsroot/monetdb/MonetDB5/src/mal/mal.mx,v retrieving revision 1.110 retrieving revision 1.111 diff -u -d -r1.110 -r1.111 --- mal.mx 17 Jan 2007 13:24:17 -0000 1.110 +++ mal.mx 31 Jan 2007 21:27:29 -0000 1.111 @@ -15,30 +15,6 @@ @' All Rights Reserved.
@f mal -@* MonetDB Version 5 -The MonetDB product family consists of a large number of components -developed within our group over the last decade. Some components have -already been shipped to happy customers, some are still in the making, -and others have found a resting place in the attic. - -The MonetDB architecture is designed to accommodate a wide-spectrum -of standardized query language front-ends (SQL, XQuery), -a variety of query transformation schemes, and -different execution platforms (interpreted materialized or -pipelined, dynamic compilation). - -MonetDB Version 5 is a major release of our software infrastructure. -The most notable differences are its greatly -improved software stack and a new interface language, -which turns the database server back-end into an -abstract database machine with its associated assembly language (MAL). -It supports backward compatibility of interfaces, tools, and -source sharing where feasible within the limited scope of resources available. - -In the remainder of this section we shortly introduce the -MonetDB Version 5 design considerations and -a quick overview of its architecture. - @node Design Considerations, Architecture Overview, Design Overview, Design Overview @+ Design Considerations Redesign of the MonetDB software stack was driven by the need to
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |
Stefan Manegold wrote:
On Wed, Jan 31, 2007 at 09:27:31PM +0000, Martin Kersten wrote:
Update of /cvsroot/monetdb/MonetDB5/src/mal In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv31774
Modified Files: mal.mx mal_instruction.mx mal_resolve.mx Log Message: mal.mx mal_resolve.mx, website documentation
is the new website built for the development trunk or from the release branch? Niels knows.
with the old website, it used to be the latter...
mal_instruction, protect against too many variables.
these were checked-in the development trunk, but the message sounds less like "new features" rather more like "bug fixes" --- aren't they also relevant for the release branch and a possible bugfix release? Well that's a philosophical question that will challenge us forever. Yes, it solves a potential bug in the stable. No, it is new behaviour, because I didn't expected large programs.
Also, some bug fixes may involve many areas and quite some time, it puts us in the position to ask this question on a more or less daily basis. My position would be that bugfixes relate to official bugreports, the rest is the 'normal' evolution. Bugfixes then should 'somehow' be propagated to the stable and made available thru nightly builds. A workable method is required, because people (starting with me) are definitely to forget to maintain two branches continously.
On Wed, Jan 31, 2007 at 10:45:44PM +0100, Martin Kersten wrote:
Stefan Manegold wrote:
On Wed, Jan 31, 2007 at 09:27:31PM +0000, Martin Kersten wrote:
Update of /cvsroot/monetdb/MonetDB5/src/mal In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv31774
Modified Files: mal.mx mal_instruction.mx mal_resolve.mx Log Message: mal.mx mal_resolve.mx, website documentation
is the new website built for the development trunk or from the release branch? Niels knows. All of you too, copy.sh has
export WHICH=Stable
with the old website, it used to be the latter...
mal_instruction, protect against too many variables.
these were checked-in the development trunk, but the message sounds less like "new features" rather more like "bug fixes" --- aren't they also relevant for the release branch and a possible bugfix release?
Well that's a philosophical question that will challenge us forever. Yes, it solves a potential bug in the stable. No, it is new behaviour, because I didn't expected large programs.
Also, some bug fixes may involve many areas and quite some time, it puts us in the position to ask this question on a more or less daily basis. My position would be that bugfixes relate to official bugreports, the rest is the 'normal' evolution. Bugfixes then should 'somehow' be propagated to the stable and made available thru nightly builds.
A workable method is required, because people (starting with me) are definitely to forget to maintain two branches continously. Two branches isn't a lot to keep up with. Back porting and therefor manualy forwaring changes to the development branch is much more complicated!
So the rule is simple bug fixes (all) go to the release branch and all features go to the development branch Very clear ... Niels
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
On Wed, Jan 31, 2007 at 10:45:44PM +0100, Martin Kersten wrote:
Stefan Manegold wrote:
On Wed, Jan 31, 2007 at 09:27:31PM +0000, Martin Kersten wrote:
Update of /cvsroot/monetdb/MonetDB5/src/mal In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv31774
Modified Files: mal.mx mal_instruction.mx mal_resolve.mx Log Message: mal.mx mal_resolve.mx, website documentation
is the new website built for the development trunk or from the release branch? Niels knows.
with the old website, it used to be the latter...
mal_instruction, protect against too many variables.
these were checked-in the development trunk, but the message sounds less like "new features" rather more like "bug fixes" --- aren't they also relevant for the release branch and a possible bugfix release? Well that's a philosophical question that will challenge us forever. Yes, it solves a potential bug in the stable. No, it is new behaviour, because I didn't expected large programs.
well, I just wanted to make sure that each developer is aware of where his/her checkins go --- development branch means development branch, only. If that's the developer's choice, that's fine with me.
Also, some bug fixes may involve many areas and quite some time, it puts us in the position to ask this question on a more or less daily basis. My position would be that bugfixes relate to official bugreports, the rest is the 'normal' evolution.
Fine with me. As said, I consider it the developer's choice (and hence "responsibility").
Bugfixes then should 'somehow' be propagated to the stable and made available thru nightly builds.
There is no "ma[gn]ic" to do this "somehow" --- mainly because who else can answer the "philosophical" question whether a change is a bug fix or a new feature, if not (even) the developer him/herself?? (Semi-) automa[tgn]ic propagation of bug fixes from the release branch to the development trunk do work with reasonable effort only in this one direction and only in a rather "controlled" way. Basically, propagation can IMHO only be handled if it is done (semi-)automa[tgn]ic" as we do it now, which does not allow to select single checkins, but rather only works "in bulk": all checkins are propagated. Any selective back-porting of single checkins from the development trunk to the release banch requires each single propagation (per checkin AND file) to be done by hand... Moreover, once back-ported, these changes will be propagated with the next (semi-automa[tgn]ic branch->trunk propagation, and can hence easily lead to conflicts ... Once we start propagating "back-and-forth", I'll deny any resposibility for conflict, lost or "messed-up" checkins; this also means, I then can nolonger "guarantee" the proper propagation of bug fixes from the release branch to the development trunk.
A workable method is required, because people (starting with me) are definitely to forget to maintain two branches continously.
Well, I guess that's just "human" --- users than have to move to the development trunk or wait for the next released --- with all other consequences... Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |
participants (3)
-
Martin Kersten -
Niels Nes -
Stefan Manegold