From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 84360201A44 for ; Tue, 26 Apr 2011 08:34:47 -0700 (PDT) Received: by iwn8 with SMTP id 8so938487iwn.16 for ; Tue, 26 Apr 2011 08:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=HSNjN6AqpKE/FnNPPbmbjDpluQJXyUfOFlKWOa4FFgE=; b=phYzYe17i+Gc526hQhDxcPy+GDtbPDmVbIbK1+SoTN/MmIhiBX6c1BAILCtMNnqfnk iNQgRmynAYyPpQ+V5zECbCwL2zkBFiFbYLXtZS2EEiaeksCekfKiDBGYkItR69s18rcB NVVioLnaGXD0HFCqORP2QktEpbmp/WaquaU5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lmbzJjxzD1oohB3nXfgkbxuz83fe1kXOsrWexyrIT82EaQt8K3ETXUzVRbcVdoiWsh 31otWtYGJh70pd+3NIFB9dOgwqZ/Sst2g6kwIcQPwi9QJDmmeEC2qgCO0wp3jJFdDKC/ ZAah6zdg7us9s1gZmcvTGj3a0OiHLq8PEw/jQ= MIME-Version: 1.0 Received: by 10.231.201.76 with SMTP id ez12mr670775ibb.96.1303832103097; Tue, 26 Apr 2011 08:35:03 -0700 (PDT) Received: by 10.231.34.77 with HTTP; Tue, 26 Apr 2011 08:35:03 -0700 (PDT) Date: Tue, 26 Apr 2011 09:35:03 -0600 Message-ID: From: Dave Taht To: bismark-devel@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Bismark-devel] some thoughts on continuous builds X-BeenThere: bismark-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: BISMark related software development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 15:34:47 -0000 The advantage of a continuous build and test system is that you catch new bugs early, as they occur in your external trees, and also fold in fixes to existing bugs and new features quickly. A disadvantage is that new bugs occur and invalidate previous testing. At some point in the near future we will need to freeze bismark, starting with the kernel and core utilities, do extensive QA, and ship. Until then, builds should be done weekly (preferably daily) Up until now I have been doing pulls and builds on a rather arbitrary sched= ule. In my judgement there are still sufficient bugs outstanding http://www.bufferbloat.net/projects/bismark/issues to be doing continuous builds but I haven't been in the loop this week (I will be more available after may 1) So I would like to establish a process whereby we have a trigger point for doing a new major build, and trigger points for new minor ones. One nice thing about having multiple builders is that it's possible to at least test the new stuff before committing to using it on other people. For example, last night, on my own tree, in my home dir, I did the usual cd ~/src/openwrt; git pull # looked over the logs with git log, saw a few interesting changes cd ~/src/wndr370 ./scripts/feeds update # this updates the external packages and rarely breaks anything git pull # in my case this pulls from my private copy of openwrt make menuconfig # and save. you have to do this fairly often as options do change echo make -j 8 | batch And the latest and greatest stuff did, indeed, build. Now, (due to me not paying attention this week) I am still a bit out of sync with what's going on in the core ~bismark tree, and don't have the hardware to test against right now, but I have a reasonable confidence level that the main trees could be updated and built against. So, anyway, whenever y'all get to a good "do a complete build" point, please do so? The pain you incur now will be saved later. (I hope to be testing a new build w/hardware saturday) --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com