Historic archive of defunct list bismark-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: bismark-devel@lists.bufferbloat.net
Subject: [Bismark-devel] some thoughts on continuous builds
Date: Tue, 26 Apr 2011 09:35:03 -0600	[thread overview]
Message-ID: <BANLkTikGwkDfxqoecun=qX8bXdiJFQmCeA@mail.gmail.com> (raw)

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 schedule.

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)

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

             reply	other threads:[~2011-04-26 15:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-26 15:35 Dave Taht [this message]
2011-04-26 15:37 ` Nick Feamster
2011-04-26 15:55   ` Dave Taht
2011-04-26 16:07     ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTikGwkDfxqoecun=qX8bXdiJFQmCeA@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=bismark-devel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox