[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
Stefan.Manegold at cwi.nl
Wed Jan 31 23:25:16 CET 2007
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
> 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
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
| Dr. Stefan Manegold | mailto:Stefan.Manegold at 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 |
More information about the developers-list