Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Availability of old build results
Date: Fri, 6 Dec 2013 09:50:43 +0100	[thread overview]
Message-ID: <20131206095043.361b3fc4@skate> (raw)
In-Reply-To: <874n6mfjsp.fsf@dell.be.48ers.dk>

Dear Peter Korsgaard,

On Fri, 06 Dec 2013 09:47:02 +0100, Peter Korsgaard wrote:

>  > 1. During the time -next is opened (until release) we also make test
>  > builds on that branch (but keep the results separate from the master
>  > results, of course).
>  > Pros:
>  >   - better visibility on the quality of -next, before it is being
>  > merged, and a chance to fix the problem beforehand
>  > Cons:
>  >   - attention of developers is diverted away from stabilizing the
>  > upcoming release
>  >   - autobuild computing capacity is diverted away too
> 
> Yeah, I'm not quite sure if this is a good idea.

It would however be the easiest thing to do.

>  > 2. Similar, in a way: when patches are posted to the list (not only
>  > during the stabilization month), run them through some autobuild
>  > configurations 'automatically' to try catching common problems (for
>  > example thread support, mmu support, uclibc problems, ...) and post
>  > the results somewhere. This generates a kind of 'staging moment' for
>  > patches before they get applied, to check their quality.
>  > Whether this should be done for all patches (even at their initial
>  > send) or only makes sense for patches that have been reviewed first
>  > (to make sure the computing power is used usefully) is something that
>  > can be discussed. In the latter case, we'd need to have a trigger to
>  > request the test builds.
> 
> This one I like! Seems like a nice little weekend task to
> implement. I'll try to find time for it (but others are certainly
> welcome to work on it as well)

I'm not sure to understand how this will work. Which patches will be
run through this testing? Who will decide which patches will go? You?
The patch submitter?

On my side, I'm really skeptical about that one: I think we should
rather merge patches faster, so that we simply rely on the existing
autobuilder infrastructure, which works well.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2013-12-06  8:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05 23:25 [Buildroot] Availability of old build results Thomas Petazzoni
2013-12-05 23:41 ` Yann E. MORIN
2013-12-06  7:36   ` Thomas De Schampheleire
2013-12-06  8:47     ` Peter Korsgaard
2013-12-06  8:50       ` Thomas Petazzoni [this message]
2013-12-06  9:57         ` Thomas De Schampheleire
2013-12-06 10:11           ` Thomas Petazzoni
2013-12-07 20:43             ` Thomas De Schampheleire
2013-12-06 16:10           ` Arnout Vandecappelle

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=20131206095043.361b3fc4@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.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