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

Thomas De Schampheleire patrickdepinguin at gmail.com
Thu Oct 31 17:10:36 UTC 2013


Hi Thomas,

On Thu, Oct 31, 2013 at 3:55 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> 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.

Ah, I had interpreted this branch according to the strategy discussed
at last BDD regarding the community organization. In that discussion,
such aggregation of submitted patches was also proposed. I thought you
were acting in that mode.

In that more general case, where there would me more than one
maintainer-proxy, the exact strategy is still somewhat unclear to me.

Best regards,
Thomas



More information about the buildroot mailing list