Hi Stefan,

Perhaps an override would be helpful as well. I imagine that you'd want from time to time say "that's an important check-in; I'd like it to be tested tonight".

Perhaps the one or two branches issue need not be decided upfront. If you simply measure how much time a test-cycle takes as an average over, say, the last 5 cycles, and you specify what the time-window is for testing, then the 'test control script' could decide itself whether or not there is enough time for another test-cycle. Such an approach can be combined with a priority list for branches as you proposed below.

Third idea, or rather a question, was your proposal for all modules individually (e.g., change to branch X in "MonetDB4", then perform all tests of that module and modules that depend on it) or for all modules combined (i.e., change in some module in branch X, then perform all tests of all modules)? The former has higher granularity, so may allow more targeted test-cycles to be performed during the night (for example, if combined with the previous idea).

Just my 2cents. Maurice.

Stefan Manegold wrote:

Sjoerd,

thank you very much for creating the new branch.

Fellow developers,

with the new branch, we now should extend our nightly testing to test all three branches, i.e., Stable "Aug2009", next Stable "Nov2009", and Current (trunk).

However, not only is a night (and recntly often a day) to short for that, given the amount of compiling & testing we need/want to do, and the hardware resource we have access to, but also there is not sufficient storage space to keep a back-log of both nightly builds and testing result for the most recent 30 days for all three branches.

Hence, I'd have some idea(s?) to share: Instead of testing all three (not possible) or a fixed subset of two (which?) branches per night, we could head toward testing two (or even only one) branch per night, determining the branch(es) to be tested as follows:

• test only one branch:

  • If there have been checkins to the Stable (Aug2009), then test this one;
  • else, if there have been checkins to the next Stable (Nov2009), then test it;
  • else, if there have been checkins to the Current (trunk), then test it;
  • otherwise (no checkins), test the branch that has not been tested for the longest time.

• test two of the three branches:

  • If there have been checkins to all three branches, test Stable (Aug2009) & next Stable (Nov2009);
  • else, if there have been checkins to two branches, test these two branches;
  • else, if there have been checkins to one branch, test this one plus the one of the other two that has not been tested for the longest time.
  • otherwise (no checkins), test the two branches that has not been tested for the longest time.

I haven't thought about how exactly to implement this, and how to properly document / present it to make transparent which exact code version (and "machine status") which testing results reflect to avoid confusion ...

Any comments or other ideas are more than welcome.

Regards, Stefan

On Mon, Sep 28, 2009 at 05:16:34PM +0200, Sjoerd Mullender wrote:

...

I have created a new branch which is to be used for the upcoming Nov2009 release. This branch is called "Nov2009".

There are now two "stable" branches, the Aug2009 and Nov2009 branch. The Aug2009 branch will be used for the Aug2009-SP2 release which is scheduled for October. The Nov2009 branch will be used for the Nov2009 feature release in November (and the Nov2009-SP1 and Nov2009-SP2 releases in December and January).

The reason for making the Nov2009 branch now, and not waiting until after the Aug2009-SP2 release is that this way there is more time to stabilize the code for the release.

There are a number of new features that are planned for the November release. Some of these features are not completed yet, and all of these features have to be properly tested and fixed if they're broken. The not-yet-completed features *must* be completed before the end of October, or else they *will* be removed from the release.

New features for the November 2009 release are:

• new SQL import from CSV files
• new code for large joins
• monetdb/merovingian distribution
• database replication
• native PHP client
• others?

Features that will definitely not be part of the November 2009 release include:

• Stratos's slicing and histogram stuff
• more?

These will be removed from the Nov2009 branch but of course kept in the development trunk.

All developers *must* now decide where each change they want to make to the code belongs.

If a bug occurs in the Aug2009 branch, the bug *must* be fixed in that branch. If a bug does not occur in the Aug2009 branch, but it does occur in the Nov2009 branch, it *must* be fixed in the Nov2009 branch (this includes fixes to complete the above-mentioned features). All other changes *must* go to the development trunk.

Propagation will be done from the Aug2009 branch to the Nov2009 branch, and from the Nov2009 branch to the development trunk.

-- Sjoerd Mullender

...

---

Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers