[Monetdb-developers] Important Announcement: New release branch

Keulen, M. van (Maurice) m.vankeulen at utwente.nl
Tue Sep 29 10:29:08 CEST 2009


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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/monetdb-developers
>>     
>
>
>   

-- 
----------------------------------------------------------------------
Dr.Ir. M. van Keulen - Assistant Professor, Data Management Technology
Univ. of Twente, Dept of EEMCS, POBox 217, 7500 AE Enschede, Netherlands
Email: m.vankeulen at utwente.nl, Phone: +31 534893688, Fax: +31 534892927
Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen





More information about the developers-list mailing list