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 |