From: Joshua Lock <josh@openedhand.com>
To: poky@yoctoproject.org
Subject: Re: Master Stability
Date: Wed, 08 Dec 2010 12:14:44 +0000 [thread overview]
Message-ID: <1291810484.2516.3.camel@scimitar> (raw)
In-Reply-To: <4CFE82DC.5020608@intel.com>
On Tue, 2010-12-07 at 10:54 -0800, Scott Garman wrote:
> On 12/07/2010 10:43 AM, Joshua Lock wrote:
> > On Tue, 2010-12-07 at 09:44 -0800, Elizabeth Flanagan wrote:
> >> Acked-by: Beth Flanagan
> >>
> >> (Stands on build engineer soap box)
> >>
> >> If at all possible, when you try to verify a fix, do a full clean build
> >> for more than just one arch using BB_NUMBER_THREADS and PARALLEL_MAKE.
> >> With the number of pull requests coming through, it becomes more and
> >> more vital to verify patches prior to sending them out.
> >>
> >> Preferably, I'd like to start seeing people add something like a
> >> Verified-with:<build target> tag to pull requests, so we can at least
> >> identify pulls that need more peer review than normal.
> >
> > Personally I'd like to see links to an autobuilder report showing it has
> > succeeded and if such a tag is *not* on a pull request it's
> > automatically pushed to an autobuilder instance with the success of the
> > build sent back to the list as a reply to the patch thread.
> >
> > I think hardware constraints make this a bit of a pipe dream though?
>
> We're definitely hardware constrained for it. I want a pony also. ;)
I've become increasingly jealous because some colleagues have a unicorn!
It's called git test-sequence:
http://dustin.github.com/2010/03/28/git-test-sequence.html
>
> Beth has started working on customizing Buildbot's web interface to
> allow finer-grained control over what gets built. A longer-range goal of
> this is eventually be able to pick which targets and architectures get
> built from a custom autobuilder buildset. That way someone with a commit
> to quilt (which has very few dependencies) wouldn't have to build all of
> poky-image-sato to demonstrate their build works. With something like
> that in place, we can start to consider having individual developers
> test their changes on our autobuilder infrastructure. Which would kick ass.
No kidding, can't wait!
Hopefully we can tie something like git test-sequence into this such
that we can do these things from our lovely shell environments :-)
Cheers,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre
next prev parent reply other threads:[~2010-12-08 12:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 1:58 Master Stability Saul Wold
2010-12-07 17:44 ` Elizabeth Flanagan
2010-12-07 18:43 ` Joshua Lock
2010-12-07 18:54 ` Scott Garman
2010-12-07 21:27 ` deVries, Alex
2010-12-08 1:06 ` Stewart, David C
2010-12-08 1:16 ` Saul Wold
2010-12-08 12:14 ` Joshua Lock [this message]
2010-12-08 2:59 ` Tian, Kevin
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=1291810484.2516.3.camel@scimitar \
--to=josh@openedhand.com \
--cc=poky@yoctoproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.