From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: testing 2010-12-10 (wiki, results, bluez-libs)
Date: Thu, 16 Dec 2010 07:55:27 -0800 [thread overview]
Message-ID: <20101216155527.GC22134@gmail.com> (raw)
In-Reply-To: <AANLkTimuRa8EC=U_CvgiZV1tWySg_AQTwWBQTxdpv7Zn@mail.gmail.com>
On (16/12/10 08:33), Cliff Brake wrote:
> On Wed, Dec 15, 2010 at 9:43 AM, Tom Rini <tom_rini@mentor.com> wrote:
> > On 12/15/2010 12:51 AM, Frans Meulenbroeks wrote:
> >>
> >> Dear all,
> >>
> >> I just wanted to update the testing table with my entries and I
> >> noticed two (possibly related) things.
> >> - no other entries for 2010-12-10 are there yet (and it is already
> >> wednesday)
> >
> > I haven't updated the stuff we're building since just about everything
> > failed due to the gcc issue Khem fixed in
> > 2c8570552549da2e11428d08b2bc08849cac39b1. This is why I sometimes wonder if
> > it would be desirable to cherry-pick a few things in to the testing-next
> > branch.
>
> One of my concerns is coordinating with all the people doing testing
> if we start committing to the testing-next branch. How do we know who
> restarted builds, etc. I guess we could assume the cherry-picked
> changes would be minor enough that people who have already finished
> builds would not need to re-build.
yeah without autobuilder which triggers a build on everycommit
its hard
>
> At this point I'm just more inclined if the weekly testing branch
> crashes and burns horribly to just throw away that week, and focus on
> getting things fixed in the master for next week. Its not perfect,
> but with so many people participating, it seems like we need to keep
> it as simple as possible. But, keep the ideas flowing, and perhaps
> something better will emerge.
I think the current method is good. What I do is if I see a problem
in the testing then I fix it there locally and keep going with build to
find more and apply the patch to master
for next cycle so far it has worked well.
>
> Thanks,
> Cliff
>
> --
> =================
> http://bec-systems.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
prev parent reply other threads:[~2010-12-16 15:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 7:51 testing 2010-12-10 (wiki, results, bluez-libs) Frans Meulenbroeks
2010-12-15 14:43 ` Tom Rini
2010-12-15 15:33 ` Frans Meulenbroeks
2010-12-15 17:23 ` Tom Rini
2010-12-15 18:41 ` Frans Meulenbroeks
2010-12-16 13:33 ` Cliff Brake
2010-12-16 15:55 ` Khem Raj [this message]
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=20101216155527.GC22134@gmail.com \
--to=raj.khem@gmail.com \
--cc=openembedded-devel@lists.openembedded.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.