[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 31 Oct 2013 13:45:43 +0100, Thomas De Schampheleire wrote:

> I think we need a single strategy to be used by all maintainer-proxies.
> The problem with not resending the patches is that the
> maintainer-proxy (or whatever you want to call it) needs to have a git
> tree accessible by Peter. Although not impossible, I'm not really fond
> of it.
> 
> Also, consider this scenario: a developer submits a patch on day 1, a
> maintainer-proxy adds the patch to his branch on day 2. However,
> another contributer gives some remarks on the patch and expects it to
> be reworked. The maintainer-proxy could forget about this when v2 of
> that patch is sent. In this case, v2 is pending in patchwork, and v1
> is on a branch for which a pull request is sent. The actual contents
> of the branch is not visible on the list. This opens a window for
> errors. By sending the patches to the list, there is a bit more
> visibility. The downside is that the list gets additional mails.
> 
> An additional question is: is there a policy on who takes which
> patches, if certain actions need to be taken on these patches, etc.?
> At this moment, I still don't really see the difference between
> providing an Acked-by: and adding a patch to a for-peter branch,
> except for the fact that incoming patches are prearranged in batches
> for Peter.

What I merely intended to do with the for-peter-2013.11 is to act
more-or-less as an interim maintainer during the short period Peter is
not available. I've done this before (i.e not having commit access to
the official repository, but gathering relevant patches in a branch,
until Peter comes back). The idea here is that there would be only one
such 'interim maintainer' at a given point in time.

And yes, the only difference between the for-peter-2013.11 branch and
Acked-by is simply that the batch of patches is already prepared for
Peter to review and pull, he doesn't have to go in the list and/or
patchwork and filter out which patches he should have a look right now,
and which patches are anyway delayed to 2014.02.

Best regards,

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