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:[EMAIL PROTECTED] | | 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 | ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-developers
